What happens in a technical due diligence?

A technical due diligence is an independent review of a company’s technology before an investment or acquisition. It looks at the code, the infrastructure, security, the team and how well the platform can grow. The findings become risks the buyer can price in, plan to fix or treat as a reason to walk away. Most of our engagements take one to three weeks.

What does it cover?

The scope depends on the deal, but these areas come up almost every time:

• The codebase: quality, architecture, technical debt and how hard the code would be to hand over to new people.
• Infrastructure: how the platform runs, what it costs to operate and whether those costs grow faster than the business.
• Security and compliance: security architecture, known vulnerabilities, data protection and, where it applies, GDPR.
• Team and process: development practices, documentation and how knowledge is spread across the team.
• Scalability: what breaks first when usage grows, and roughly what it costs to fix.
• Integration: for an acquirer, how well the platform fits existing systems and how long a migration would take.

How does the process work?

1. We agree on scope and sign a confidentiality agreement. A review that tries to cover everything ends up shallow everywhere, so this step decides how useful the result will be.
2. We get access to documentation, code repositories, cloud accounts or cost reports, and time with the people who built the system.
3. We review each area systematically and interview the team.
4. We classify each risk by severity, so that a missing test suite is not weighed the same as unclear ownership of the core code.
5. We write recommendations with estimates of what remediation would take in time and money.
6. We deliver an executive summary for the decision makers, with the details behind it for the technical team.

What do you get at the end?

You get the risks ranked, with enough detail to act on: a risk matrix, recommendations with remediation estimates and a summary written for a board or investment committee. The estimates are what make the review useful in a negotiation. They can become a price adjustment, a condition in the agreement or a plan for the first months after closing.

What should a founder prepare?

A due diligence goes faster, and gives a fairer picture, when the basics are ready. Before the review starts it helps to have:

• an up-to-date overview of the architecture
• access to the code repositories and the build pipeline
• the last year’s cloud and licence costs
• a list of open source and third-party components, with their licences
• security policies, recent penetration tests and a record of any incidents
• an overview of the team and who knows what

None of this needs to be polished. Reviewers mainly want to see that the company knows its own system.

Which findings change a deal?

Some findings matter far more than others. These are the ones we see shift terms most often:

• one or two people hold knowledge that nobody else has
• unclear ownership of the code, for example work by contractors without proper agreements
• open source licences that conflict with how the product is sold
• no automated tests or deployment, so every release depends on manual steps
• missing security basics, such as multi-factor authentication or backups that have been restored in a test
• cloud costs that grow faster than revenue

Why we look from both sides of the table

We have built companies and raised money for them ourselves, and we have assessed others on behalf of investors and acquirers. That helps in both directions. We know what a buyer needs answered, and we know why a founder can be nervous about showing a system that was built under time pressure. We review with that understanding and report honestly.

Read more about our technical due diligence, or send us a confidential inquiry.