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.
Lawyers call it technology due diligence. The fund’s template says tech DD. The line in the plan says technical due diligence. One piece of work under three names: somebody independent looks at the software business you’re about to put money into and says whether the technology is worth the price.
Here’s how it runs when I do it, from the first call to the report.
It starts with your question
I want to know what decision the review feeds. “Is the code any good” doesn’t help me, because whatever I answer you’ll do the same thing.
Better ones: does the technology support the valuation? Can this team build the next eighteen months of the plan? Who could it not survive losing?
The question sets the scope and the scope sets the days, because an investor taking a minority stake and leaving the founders in charge needs a different review from an acquirer who’ll be running the platform by Christmas and wants to know what they’re inheriting.
The access it needs
Three things, agreed before the clock starts.
The repository. Read access to the real one, with its history. A zip of the current code hides how the team works.
The infrastructure. Where it runs, what it costs a month, who holds the keys. A lot of risk lives here, in an account registered to a founder’s personal email, a database with one copy, or a certificate expiring in March that only one person knows about.
An hour each with the people who built it. The code shows what was built, but the people tell you why, and which part worries them.
A seller who won’t give read access to the repository is telling you something, and it goes in the report either way.
What gets read, and in what order
The order that finds the costly problems first.
Ownership and dependency: who owns the code, which licences it carries, and which third-party services it can’t run without. A product built on a supplier’s platform under terms that forbid assignment 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. Then how the team ships. Then security and personal data. Code quality comes last, because tidy code on the wrong architecture doesn’t help you. When the product is mostly bought-in services stitched together, the contracts might be most of the review, and I’d move them up.
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.
The reading is the part that runs to time. What stretches a review is access. Access promised for Monday arrives on Thursday, the NDA goes round three sets of lawyers, and the one engineer who understands billing is on holiday. Build that into your timetable, because the completion date won’t move for any of it, and I’d sooner a slip showed up against a plan somebody wrote in week one.
What you get at the end
The first paragraph is a position you can act on. The risks follow, ranked by what each would cost you, and the engineering detail sits at the back. I’ve written separately about what belongs in a technical due diligence report.
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
Don’t rehearse. “We know about that, it would take about three weeks, and we haven’t done it because of this” is the best answer you can give.
And run the review on yourself first, in the order above, because a problem you disclose costs you a little in the negotiation and one they find costs you their trust in everything else you’ve said.