How technical due diligence works, from the first call to the report
What gets looked at, what access it needs, how long it takes and what slows it down. Written for the investor with a deadline and the founder on the other side of it.
You have a term sheet, a completion date, and a line in the plan that says “technical due diligence”. Your lawyers call it technology due diligence, the fund’s template says tech DD, and the seller’s adviser has written IT due diligence. It’s one piece of work. Somebody independent looks at the software business you’re about to put money into and tells you whether the technology is worth the price.
Here is how it runs when I do it, and where the time goes.
It starts with your question
Before anybody opens a repository, I want to know what decision the review feeds. “Is the code any good” is a poor brief, because no answer to it changes what you do.
These are better. Does the technology support the valuation? Can this team build the next eighteen months of the plan? What would I own on day one, and what does it depend on that I wouldn’t own? If two named people left, what stops working?
The question sets the scope, and the scope sets the days. An investor taking a minority stake needs a different review from an acquirer who’ll be running the platform by Christmas.
The access it needs
Three things, agreed before the clock starts.
The repository. Read access to the real one, with its history. A zip file of the current code hides how the team works: who commits, how changes get reviewed, what happened the last time something broke.
The infrastructure. Where it runs, what it costs a month, who holds the keys. A surprising amount of risk lives here, in an account registered to a founder’s personal email or a database with one copy.
An hour each with the people who built it. The code says what was built. The people say why, and what they’d do differently, and which part they’re afraid of. That last answer is worth more than any scan.
A seller who won’t give read access to the repository is telling you something. It may be innocent. Put it in the report either way.
What gets read, and in what order
I read in the order that finds expensive problems first.
Ownership and dependency come first. Who owns the code, which licences it carries, which third-party services it can’t run without, and what those contracts say. A product built on a supplier’s platform under terms that forbid assignment is a finding that can stop a deal, and it takes an hour to find.
Then architecture: whether the design can carry the growth in the plan, and what it’ll cost when it can’t. After that the way the team ships, which means tests, releases, and how long a fix takes to reach a customer. Then security and the handling of personal data. Code quality comes last, because tidy code on the wrong architecture is still the wrong architecture.
How long it takes
The days are agreed before the review starts, so you know the total before you commit. For one product and one team I scope it in days. If somebody quotes weeks for that, ask what the extra time buys you.
What stretches a review is seldom the reading. Access promised for Monday arrives on Thursday. An NDA goes round three sets of lawyers. The one engineer who understands the billing system is on holiday. Build those into your timetable, because the completion date won’t move for them.
Where something can’t be seen in the time, the report says so. A gap you know about is worth more than a clean page.
What you get at the end
A position you can act on, in the first paragraph. Then the risks, ranked by what each would cost you, with the reasoning shown. The engineering detail sits behind that for whoever wants to check it. I’ve written separately about what belongs in a technical due diligence report and how to tell a useful one from a long one.
It’s a bounded review at my published day rate. The due diligence page has the detail.
If you’re the founder being looked at
I’ve raised equity for products I built, so I’ve sat on your side of this conversation. Two things from that side.
Don’t rehearse. A reviewer who has done this before knows a rehearsed answer, and it makes them dig where they’d have moved on. “We know about that, it would take about three weeks, and we haven’t because of this” is the strongest sentence you can say in the room.
And run the review on yourself first. If you’re raising or selling within the year, have somebody on your side find the gaps while there’s still time to close them. A problem you disclose costs you a little in the negotiation. A problem they find costs you their trust in everything else you’ve told them.