A technical due diligence is not a code review. A buyer is not trying to find bugs — every codebase has bugs. They are trying to answer three questions that decide what the company is worth and what it will cost to own: Can this technology do what the thesis needs it to do? Who actually understands it? And what happens when the current team is gone?
Founders who wait for the diligence to surface those answers are negotiating from the back foot. The better move is to ask the questions of yourself first, while there is still time to change the answer.
1. Where is the key-person risk?
The single most common finding in a technical diligence is that one or two people hold the whole system in their heads. Not the org chart — the real map of who can safely change the billing logic, who knew why that integration was built the way it was, who gets the 2am call.
A buyer prices that risk directly. If the answer to "what happens if this person leaves" is a shrug, the valuation absorbs it. The fix is unglamorous and takes months, which is exactly why it has to start before the deal, not during it: write down what only lives in someone's head, and make sure a second person has actually done the dangerous work at least once.
2. Can the architecture take the next change, or only the last one?
Most systems are built to do what they currently do. The question a buyer cares about is whether they can do the next thing — the new payer, the new compliance regime, the volume the thesis assumes — without a rewrite.
A system that works today and cannot change tomorrow is a liability wearing the costume of an asset.
You find this out by looking at how the last few significant changes went. Were they surgical, or did each one require touching half the system and holding your breath? The delivery history is a more honest signal than any architecture diagram.
3. Is compliance in the design, or bolted onto the outside?
In a regulated target — healthcare, Medicare, anything touching protected data — this is where diligence gets expensive. There is a large difference between a system where HIPAA and CMS requirements shaped the architecture from the start and one where compliance is a layer of process wrapped around a system that was never designed for it.
The second kind passes audits by heroics. That is fine until the volume doubles or the rules change, at which point the heroics stop scaling and the remediation cost lands on the new owner. Surface it early and it is a line item in the plan. Surface it after close and it is a surprise.
4. What does it actually cost to run and to change?
Two numbers matter here, and neither is on the P&L in a useful form: the cost to keep the lights on, and the cost to ship something new. A team that spends most of its capacity firefighting is not going to deliver the roadmap the thesis is priced on, no matter how talented it is.
This is the finding that most often changes a plan rather than a price. It tells the buyer whether the first year after close is spent building the thesis or paying down the debt that makes the thesis possible.
The point of asking early
None of these questions require a transaction to be worth answering. They are the same questions that tell a founder where their own risk is concentrated and what it would take to build the technology story that holds up to a buyer — or to a board, or to a raise.
The teams that come through diligence well are almost never the ones with the cleanest code. They are the ones who already knew the answers, because they had asked themselves first.
Koa Partners runs technical due diligence and fractional CTO leadership for investors and operators in healthcare and regulated industries. If you are scoping a deal or want a clear read on your own technical risk before someone else forms one, [start a conversation](/cto/private-equity).