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 covers code, infrastructure, security and the team. It also tests how well the platform can grow. Its findings become risks the buyer can price in or plan to fix, and some may be reasons to walk away. Most of our engagements take one to three weeks.

What does it cover?

The scope depends on the deal. These areas come up almost every time:

• The codebase: quality, architecture, technical debt and how hard it would be to hand over to new people.
• Infrastructure, meaning how the platform runs, its operating cost and whether that cost grows faster than the business.
• Security and compliance, from security architecture and known vulnerabilities to 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 fixing it costs.

For an acquirer, integration matters too. How well does the platform fit existing systems, and how long would a migration take?

How does the process work?

1. Scope comes first, with a confidentiality agreement. It decides how useful the result will be, because a review that covers everything ends up shallow.
2. Access comes next, to documentation, code repositories, cloud accounts or cost reports, and to the people who built the system.
3. Each area is reviewed in turn, alongside interviews with the team.
4. Every risk gets a severity. That way a missing test suite does not weigh the same as unclear ownership of the core code.
5. Recommendations come with estimates of the time and money remediation would take.
6. The decision makers get an executive summary, and the technical team gets the details behind it.

What do you get at the end?

A ranked list of risks, with enough detail to act on. The report has a risk matrix, recommendations with remediation estimates and a summary written for a board or investment committee. The estimates make the review useful in a negotiation. They can become a price adjustment or 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 it starts:

• an up-to-date overview of the architecture, and of who in the team knows what
• 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

Rough documents are fine. Reviewers mainly want to see that the company knows its own system.

Which findings change a deal?

Some findings matter far more than others. Of those we see shift terms most often, two are about people and ownership: one or two people may hold knowledge that nobody else has. Or ownership of the code may be unclear, for example after work by contractors without proper agreements. In one review, contractors had written the core of the product without an IP assignment. The buyer made a signed assignment a condition for closing. The rest are technical:

• 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 tells us which questions a buyer needs answered. It also explains why a founder can be nervous about showing a system built under time pressure. We review with that in mind, and we report honestly.

Our technical due diligence page has more detail. Inquiries are confidential.