A technical due diligence report is for the person signing. What the first page has to say, the seven questions behind it, how a finding should read, and what to distrust in a report you've been handed.
You’re about to invest in a software business, or buy one, and somebody technical is going to hand you a report about it. Here’s what a technical due diligence report has to contain to be worth its fee, and how to spot one that won’t help you decide.
The first page says what the reviewer would do in your place: proceed, proceed at a lower price, proceed on conditions, or walk away. Then the three or four findings that drove it, each with a figure beside it. If you read nothing else, that page should be enough to take into the room.
A reviewer who won’t commit to a position has written you a description. (Descriptions are cheaper, and the seller’s own documentation will give you one for free.)
Every section after page one answers one of these. If the report skips one, it should say why.
Decks describe the product as it will be. The report says what runs today, who uses it, and which parts are still a prototype.
The code, and the accounts it runs in. The licences it depends on. Whether every contractor’s work is assigned in writing, and which open-source components carry terms that matter in a sale.
Every system has a few people it can’t do without. The report names the roles and says what would stop if each one left. If the answer is “releases”, that’s a price conversation, and it belongs on page one.
Will the architecture take ten times the customers, or does it need rebuilding at three? A rebuild is a cost, and it goes in the model before you sign. Pick the multiple that fits the plan: for a marketplace it might be three times the listings on the same number of customers.
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 stopped supporting last year.
How a team releases tells you more than the code does, because a team that ships predictably can fix what the review finds. Are there tests, do they run, and would they deploy on a Friday?
Security and data handling, measured against what the business has promised its customers and what its contracts say. The report should say which controls the reviewer saw working and which it only read about.
Engineers rank findings by how bad the code is. You need them ranked by what they’d cost you, because an ugly module nobody touches costs nothing and a tidy one that only one person understands can cost you the deal.
Each finding gets the same four lines. Here’s one I’ve made up, to show the shape:
Finding 4. Billing depends on one engineer. What it is: the invoicing service has no tests, and one person has changed it in the last two years. What it costs: about six weeks of a second engineer’s time to make it safe to hand over, or a retention arrangement for the one who knows it. Does it change the decision: no, if it’s priced in. How to check it: the repository history, and the hour with the team.
Most findings won’t change the decision, and the report’s job is to make the two or three that do impossible to miss, so a forty-page document that lists sixty findings at the same weight has failed at the one thing you paid for, whatever else it turned up.
Every review runs short of something. A repository that arrived late, a supplier contract nobody could find, an engineer who was on holiday the week it mattered. The report lists them.
I’d take a report with a named gap over a clean one, because a gap you know about can go into the warranties and a gap nobody mentioned can’t.
The engineering detail goes at the back: the dependency list, the architecture as found, the test results and the notes from each conversation. It’s there so your own technical adviser, or the next reviewer, can check the reasoning on page one. You shouldn’t need it to decide.
If the seller commissioned the report, or somebody else paid for it, check four things before you rely on it.
Somebody working for the other side will write this report about you. How technical due diligence works covers the order a reviewer works in and the access they’ll want.
Keep reading
You are paying an agency or an outsourced team and you cannot tell whether the work is good. Eight checks a non-technical founder can run this week, none of which needs the code.
Read itLater than most founders expect, and earlier than they'd like. Five signals that the technical decisions have outgrown the person currently making them.
Read itWork with me
I reply within one working day to arrange a free 30-minute call.