A technical due diligence checklist that prices risk, not pages

A technical due diligence audit is not a box-ticking exercise. Its job is to turn unknowns into priced risks, so a deal can be made with eyes open. Here is the checklist we work through, and what ends up in the report.

What to look at

• The codebase. Is it readable and tested, or held together by one person's memory? How much technical debt is slowing delivery right now?
• The architecture. Can it carry the growth the plan assumes, or will it need a rewrite at the next stage?
• Key-person risk. Would the system survive a key engineer leaving next month?
• Security exposure. What is the realistic attack surface, and how is sensitive data handled?
• Process and deployment. Can the team ship safely and repeatably, or is every release a held breath?

The point is not to list every flaw. It is to find the handful that change the decision or the price.

What a useful report contains

A report a non-technical partner or a lawyer cannot read has failed. The main document should be plain language: a ranked risk register, each item with a severity and a rough cost to fix, plus a short summary of what it means for the deal. The deep technical detail belongs in an appendix for whoever wants it. The best audits end in a debrief call, where the findings get walked through and weighed against the price.

Why independence is the whole point

The most important property of whoever runs your diligence is that they have no stake in the deal closing and are not angling to build the thing afterwards. An auditor who wants the follow-on work has an incentive to soften the findings. Independence is what lets a report say the parts no one wants to hear, which are usually the parts worth paying for.

This is a companion to our guide on technical due diligence for investors and founders.