Most technical due diligence answers the wrong question
The standard technical due diligence report grades code against generic standards: does it have tests, is the architecture reasonable, are the dependencies current, is the documentation adequate. These are sensible things to know. They are not the things that move a decision.
The question that actually matters when acquiring or investing in a product is not whether the code is good. It is what it will cost you to own it. A codebase that scores poorly against abstract quality criteria may cost very little to own if the business is stable, the usage is predictable, and the team knows it thoroughly. A codebase that scores well may be enormously expensive to own if one person understands why it behaves the way it does.
Grading code against generic standards is easier than answering the ownership question, because it produces an objective-looking output. But it systematically understates the risks that affect valuation and overstates the ones that are cheapest to fix.
The four things that actually matter
Four dimensions reliably predict what it will cost to own a piece of software.
What it costs to change. Software that is hard to change becomes a tax on everything done next. The indicators are not architectural purity but practical velocity: how long does a typical feature take to ship? How often do changes cause regressions? Is deployment so painful that people avoid releasing? A codebase that is technically imperfect but practically changeable is more valuable than one that is architecturally elegant but fragile.
What it costs to run. Operational costs in production — infrastructure, incident response, support burden — are frequently not modelled in an acquisition. Look at the actual bills, not the architecture diagram. Understand what happens when things go wrong: is there monitoring, is there an on-call process, are incidents documented? A system that runs quietly and cheaply is worth more than it looks. One that requires constant attention is worth less.
What happens if key people leave. Knowledge concentration is the most consistently underpriced risk in technical acquisitions. If fewer than three people understand how the system behaves in production, that knowledge will walk out with them when they go. This is not a code quality issue. It is a business continuity issue, and it belongs in the risk register, not the footnotes.
What obligations are hidden in it. Licensing, personal data handling, third-party dependencies, and contractual commitments embedded in vendor integrations all create obligations that survive an acquisition. A dependency under a license incompatible with intended use, or a system that processes personal data across jurisdictions with different regulatory frameworks, can create liabilities that are invisible in a code review.
Concentration of knowledge is usually the largest unpriced risk
Knowledge concentration appears in every technical acquisition risk list and is underpriced in nearly every deal. The reason is that it is hard to quantify, and hard-to-quantify risks tend to be assigned a token value rather than a considered one.
The evidence for it lives in the commit history, not in the code itself. Look at who has touched the most critical paths over the past twelve months. Look at the pull request review history: is there genuine review from multiple people, or is one person approving everything? Look at the incident history: who was involved in resolving the significant problems?
If the answer to all three is the same person, you have a person-shaped single point of failure. The company's technical capacity is renting that person's knowledge, and the rental is not captured in any contract. When they leave — and they will leave, because people always do — the cost of recovery is not the cost of hiring a replacement. It is the cost of recovering knowledge that was never written down, while keeping a production system running that only the departed person fully understood.
The question is not whether to proceed — knowledge concentration is a fact of life in early-stage products. The question is whether the price reflects what recovery actually costs.
How to read a test suite
A test suite is evidence about a team, not just about a codebase. What it contains and what it omits tells you how the people who built the software think about risk.
A test suite that covers business logic thoroughly and infrastructure lightly suggests a team that distinguishes between what matters and what is merely easy to test. A test suite that is large but tests only the happy path suggests a team that valued coverage as a metric. A test suite that is thin in areas where significant incidents have occurred suggests the team has not consistently learned from failure.
The absence of tests is not automatically damning, particularly in early-stage products where speed was the right priority. What matters is whether the team has a clear account of what is covered and what is not, and a credible answer to how they would detect a regression in the untested areas. A team that knows where its gaps are and has reasons for them is in a different position from one that does not know and has not thought about it.
What deployment and incident history tells you
The deployment and incident history is the most honest record of how a system actually behaves, as opposed to how it was designed to behave.
High deployment frequency is generally a positive signal: it suggests the team has built enough confidence in the system to release regularly, and that deployment is not a crisis event requiring all hands. Infrequent deployments in an actively developed product often indicate that deployment is painful and therefore avoided — and a process that is avoided tends to atrophy.
Incidents are not a mark against a system. Every production system has them. The questions are: how quickly were they detected, how quickly resolved, and what happened afterwards? An incident history with consistent detection, resolution, and a documented change in response suggests operational discipline. A history with recurring categories of failure — the same class of error appearing again and again — suggests a structural problem that has not been addressed.
Converting findings into a number
The output of technical due diligence should be a number that can move a valuation or a price, not a list of observations that the deal team does not know what to do with.
The methodology is not complicated. Identify the risks that have a plausible path to a specific cost: the recovery cost if the key engineer leaves in the first year post-acquisition, the remediation work required before the next product phase can begin, the infrastructure cost currently hidden in the acquired company's books, the compliance exposure if personal data handling turns out to be non-compliant with the acquiring entity's regulatory obligations. Estimate each conservatively. Sum them.
The number is not precise. No estimate of this kind is. What it is, is defensible — grounded in specific findings rather than a general sense that the code could be better. A counterparty can argue with a feeling. It is harder to argue with a documented, itemised estimate of what recovery would cost if the known risks materialised.
A technical review that does not produce this kind of output has not finished the job. Cataloguing problems is the beginning of due diligence, not the end of it.