Technical due diligence
What you are actually buying, in plain language.
The code is usually fine. The question is whether it can do what the deal assumes it will.
We read the code, talk to the engineers, and tell you what it will cost to do the thing the deal assumes. That is a different question from whether the software is any good, and it is the one that decides deals.
We have been on both sides of this — building the companies being examined, and examining them. It makes us harder to reassure.
What we look at
- Whether the architecture supports the plan in the financial model. Software that works fine today and cannot reach the projections is our most common finding, and the one least often said plainly.
- The team. Knowledge concentrated in one or two people is the risk that survives diligence unnoticed and bites afterwards.
- Security and data handling — at the level of what would actually happen in a breach, and who is owed what.
- Technical debt with a number on it. "There is some legacy code" is not a finding. "Six to nine engineer-months before the integration is possible" is.
How we report it
- In language the people deciding can act on. They are rarely engineers, and they are owed an understanding of the risk rather than a colour-coded grid.
- Ranked by what would change the decision. Most diligence reports bury the two findings that matter inside forty pages of findings that do not.
- With the questions we could not answer named, and what it would take to answer them.
What you get
01
A short report ranked by decision impact, with a summary that stands alone.
02
Costed remediation for anything material — engineer-months, not adjectives.
03
The key-person and security risks, named.
04
A call with your investment committee to defend the findings.
Questions
- How long does technical due diligence take?
- Usually one to three weeks depending on the size of the codebase and how quickly the target's team can make time. We can compress it when a deal timeline demands, and will tell you what that costs in confidence.
- What is the difference between technical and commercial due diligence?
- Commercial diligence asks whether the market and the numbers support the thesis. Technical diligence asks whether the software and the team can deliver what the numbers assume. They fail independently, which is why both get done.
- Is this diligence on a company or on a person?
- On a company — its codebase, architecture, team and security. Assessing an individual joining as a technical leader is a different engagement with a different method; that is technical leadership due diligence.
- Do you do this for acquirers, investors, or both?
- Both, and occasionally for a company preparing to be examined — which is the cheapest version, since the findings arrive while there is still time to fix them.
- Will you sign an NDA?
- Always, and we decline anything where we have a conflict with a portfolio position. We will tell you about the conflict rather than manage it quietly.
Track record
Coinvision was a diligence practice we built and exited. We have also been the company on the other side of the table 7 times.
The other services
AI advisory
Whether to buy it, which one, and who is accountable when it is wrong.
Technical procurement
Deciding what to buy, before a vendor decides it for you.
Forward deployed engineering
We help you pick the right ones, and we are not one of them.
Technical leadership due diligence
The technical read on the person you are about to make CTO.
Where to next
Tell us what you are deciding.