Preparing for technical due diligence: a founder’s guide

We run technical due diligence for funds, which means we usually meet founders during the most stressful weeks of their company’s life. Take this as field notes from the other side of the table: how to prepare for technical due diligence without theater, what the DD team will look at, and why the founders who come out with better terms are rarely the ones with the prettiest codebase.

You cannot rewrite five years of engineering history in ninety days, and you do not need to. What you can fix is access, hygiene, evidence, and framing, and that is where preparation pays.

What technical due diligence teams look at

A serious tech DD spends very little time on code aesthetics. We spend ours on five things: whether the architecture supports the roadmap the deal is priced on, how code travels from a laptop to production, the security basics, how concentrated the knowledge is in one or two heads, and, increasingly, whether the AI in the deck matches the AI in production.

Wherever possible, the method is live. A walkthrough of the architecture by the person who built it. The repository history, which does not lie about velocity or about who wrote what. A deployment, watched end to end. The incident channel rather than the incident policy. The data room supports all of this and replaces none of it.

The ninety days before: fix these six things

If you have a quarter before the process starts, spend it here, roughly in this order:

1. Get secrets out of the code, including the git history, and rotate anything that was ever committed.
2. Clean up access: offboard everyone who left, turn on SSO or two-factor everywhere, and be able to produce the access list in minutes.
3. Make the test and deploy story demonstrable. Whatever CI you have, make it green and honest. If coverage is thin, know where and be ready to say why.
4. Write the onboarding path: the doc a new engineer follows in week one, and an architecture diagram that matches what runs.
5. Do a dependency and license pass. Upgrade what is dangerous, and know which copyleft licenses sit in your tree before someone else finds them.
6. Get monitoring to the point where the system pages a human, and write down your last few incidents while you still remember them.

Each item maps to a standard finding that would otherwise land in the report with a severity attached, and every one of them is cheaper to fix in the quarter before than to negotiate over in the week of signing. The security items in particular are the first things a security review inside a deal will sample.

Build the data room before anyone asks

Half the friction in a DD is retrieval: the pen test that exists but nobody can find, the org chart that is eight months old. Assemble the technical data room in advance: architecture overview, security policies, test and deployment documentation, the incident log, SOC 2 or ISO artifacts if you have them, and candid metrics on uptime and delivery. Absences speak too. A missing document tells the reviewer something, so know your gaps and be ready to name them before we do.

Honesty about known debt beats polish

The strongest sell-side move we see is a self-authored technical debt register: here is what we know is weak, why we accepted the trade-off, and what fixing it would take. Founders fear that naming debt lowers the price. Our experience is the opposite. Debt we discover costs more than debt you disclose, because a discovered problem makes the buyer wonder what else was left unsaid, and that doubt spreads across every red flag in the report.

We have never audited a company with zero findings. Buyers know this. A team that says "we chose this shortcut deliberately in 2023 to land two enterprise deals, and here is the remediation plan" reads as engineering management. A team that presents a flawless story reads as either naive or rehearsed, and both invite deeper digging.

The CTO session decides more than the data room

Somewhere in the process there will be two or three hours of conversation with your technical leadership, and that interview moves the conclusion more than any document. Prepare for it by rehearsing the architecture walkthrough rather than the answers. Bring the engineer who knows, no matter their title. When you do not know, say so and say how you would find out. Reviewers calibrate on how you handle the question you did not expect, because that is the signal for how you run engineering when nobody is watching.

If you are heading into a competitive process rather than a single negotiation, it can even be worth commissioning the audit yourself and handing the report to bidders. Either way, it helps to know what the other side will run. The scope we use for technical and AI due diligence is public, the checklist is on this site, and preparing against it is fair game. We would rather audit a prepared company: the process is faster, the findings are cleaner, and everyone negotiates on facts.