Most founders picture technical due diligence as a team of engineers reading their codebase line by line, hunting for the embarrassing parts. That picture drives a lot of unnecessary panic, and it aims preparation at the wrong target.
Diligence teams rarely have time to read your code, and they know that code quality is a weak predictor of anything they care about. They are pricing risk, not reviewing craftsmanship. Specifically: what breaks after the deal, what it costs to fix, and how much of it walks out the door with three people.
What they are actually assessing
Nearly every question maps back to one of four risks.
- Key-person risk. How much of the system only one person understands. This is the single most common finding, and the one that most often changes terms.
- Continuity risk. What happens on a bad day. Whether you can restore from backup, roll back a deploy, and find out something broke before a customer tells you.
- Compliance and legal risk. License obligations in your dependency tree, where customer data lives, what you have contractually promised about it.
- Scalability risk. Not whether you can handle Google's traffic, but whether the next 10x costs a rewrite or a bigger instance.
Notice that none of those are "is the code good." A tidy codebase with one person who understands it scores worse than an ordinary one that four people ship to every week.
The questions that decide the outcome
A few questions do most of the work, and they are worth rehearsing honestly before anyone external asks them.
"Walk me through what happens when a deploy goes wrong." They want to hear a rollback, not heroics. "We revert and redeploy in about ten minutes, and here is the last time we did it" is a strong answer. "That hasn't happened" is a much weaker one than founders expect — it usually means either low deploy frequency or no visibility.
"If your lead engineer left tomorrow, what stalls?" Every company has a real answer. Naming it specifically, with the mitigation already in flight, reads as maturity. Claiming nothing would stall reads as not knowing.
"Show me how a change gets from idea to production." They are looking for a repeatable path — review, tests, deploy, monitoring — not a particular toolchain. Whatever the path is, it needs to be the same one everybody uses.
"What do you know is broken that we haven't asked about?" The trap question. Volunteering your real tech debt with cost estimates and a sequence builds enormous credibility. Getting caught omitting something destroys it, and calls every other answer into question.
How to prepare, starting six months out
The things that actually move a diligence outcome take months, because they are habits rather than documents.
- Fix bus factor first. Pair on the systems only one person touches. It is the slowest fix and the highest-value one.
- Make the boring things provable. Restore a backup and write down how long it took. Practice a rollback. Evidence beats assertion.
- Write the architecture overview once. Two pages, current, honest about known weak spots. It will be requested every time.
- Inventory your dependencies and licenses. Copyleft in a commercial product is a real deal issue and an entirely avoidable surprise.
- Keep a live debt register with costs. The same one you should already be taking to your board.
The reframe worth internalizing
Diligence is not a test you pass or fail. It is an exercise in whether your account of your own systems turns out to be accurate. Teams that describe their weaknesses precisely, with a plan and a number attached, consistently do better than teams whose story falls apart under two follow-up questions — even when the second team's technology is genuinely better.
That is also why the preparation is worth doing whether or not a transaction ever happens. Everything on the list above makes the company easier to run on an ordinary Tuesday.
If you have a round or a sale on the horizon and want to know what a diligence team will find, let's talk — we would rather you hear it from us first.