A technical due diligence checklist that prices risk, not pages

You are about to wire half a million euros into a company whose product you have never seen the inside of. The founder says the codebase is solid. The deck says the architecture scales. A technical due diligence audit is not a box-ticking exercise. Its job is to turn those claims into priced risks, so the deal gets 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. "No automated tests, six months to retrofit" tells a partner more than ten pages of coverage metrics. 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, because a number on a page lands differently once someone explains what breaks if you ignore it.

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.