What belongs in a technical due diligence report
The report is for the person signing, and most are written for the engineers. The seven things it has to answer, and how to tell a useful one from a long one.
You’re about to invest in a software business, or buy one. Somebody technical will look at it for you and write a report. The report will be forty pages long, it will score the codebase out of ten in a dozen categories, and you’ll finish it no clearer about whether to sign.
That’s a report written for engineers. Yours has one reader, and that reader has a decision to make.
Start with the position
The first page should say what the reviewer would do in your place, and why. Proceed, proceed at a lower price, proceed on conditions, or walk away. Everything after that page is there so you can check the reasoning.
A reviewer who won’t commit to a position has handed the judgement back to you, and judgement was the thing you were paying for.
The seven questions
1. Is the product what the deck says it is?
Decks describe the product as it will be. The review describes it as it is: what runs today, what is a prototype, and what is a slide. The gap between the two is the first thing a buyer needs to see.
2. What would you own on day one?
Code, certainly. But also: who owns the accounts it runs in, which licences it depends on, what was written by contractors and whether the paperwork assigns it, and which open-source components carry terms that matter in a sale.
3. Who does it depend on?
Every system has people it can’t do without. Find out how many, and who. If two named engineers leaving would stop releases, that’s a price conversation, and it belongs near the front of the report.
4. Will it carry the plan?
The investment case assumes growth. Will the architecture take ten times the customers, or does it need rebuilding at three? A rebuild needn’t end the deal. It’s a cost, and it should be in the model before you sign instead of after.
5. What does it cost to keep?
Hosting, licences, third-party services, and any AI spend charged per call. Then the maintenance nobody budgeted for: the framework two major versions behind, the component its vendor has stopped supporting. These are known, countable costs and the report should count them.
6. How is it built and shipped?
How a team releases tells you more than the code does. Are there tests, and do they run? Can they deploy on a Friday? When something broke last, how did they find out? A team that ships predictably can fix what the review finds. A team that can’t is the larger risk.
7. Is the data safe, and would it survive an audit?
Security and data handling, measured against what the business has promised its customers. I implemented ISO 9001, 14001 and 27001 in a business I owned, and the lesson that stuck is that a control on paper and a control people follow are different things. The report should say which kind it found.
Rank by money, not by severity
Engineers rank findings by how bad the code is. You need them ranked by what they would cost you. An ugly module nobody touches is cheap. A tidy system that only one person understands is expensive.
Each finding should carry three things: what it is, what it would cost to fix or to live with, and whether it changes the decision. Most will not. The report’s job is to make the two or three that do impossible to miss.
What it must say it didn’t see
Deal timetables are short and access is partial. A useful report says what the reviewer couldn’t look at, and what that leaves open. I’d take a report with a named gap over a clean one, because a gap you know about can go into the warranties.
If you’re the founder
Everything above will be done to you, by somebody working for the other side. I’ve raised equity for products I built, and I’ve sat in that seat.
Run the review on yourself first. A gap the investor’s adviser finds is a negotiating point. The same gap found by you six months earlier is a line on a roadmap, and by the time anyone asks, it’s closed.