Technical due diligence has a failure mode that looks like thoroughness. The report runs to sixty pages, lists every linting violation and outdated package, scores the codebase against a maturity model, and leaves the reader knowing a great deal without being able to decide anything.
The question a buyer is actually asking is narrower and harder: what will it cost to own this, and what could go wrong that we have not priced?
Everything in a good report exists to answer that.
Code quality is a proxy, and a weak one
Codebases that read badly are often fine to own. Codebases that read well are sometimes not. What matters is not how the code looks but whether it can absorb change at the rate the investment case assumes.
The signals that actually predict future cost:
How long a change takes end to end. Not how long it takes to write, but how long from decision to production. That number captures the build, the tests, the review process, the environments and the release mechanics all at once, and it is very hard to fake.
Whether anyone can work in it. If four engineers can each pick up any ticket, the codebase is healthy regardless of its style. If work has to be routed to specific people, the constraint is real and it will not resolve on its own.
What happens when something breaks. How incidents are found, how they are diagnosed, how often the answer is that one person logs onto a server and looks around.
Test coverage where it matters. Not the percentage. Whether the parts that carry financial or regulatory risk have tests that would actually catch a regression.
A report that leads with cyclomatic complexity and duplication percentages is measuring what is easy to measure.
Key-person risk is usually the largest unpriced item
In most small engineering organisations, one or two people hold the mental model of how the system really works. Not the documented architecture, the actual one: why that queue exists, what breaks if the nightly job is late, which client has the special case.
This rarely appears in a data room. It shows up in interviews, in commit history concentration, and in the answers you get when you ask two different engineers the same question about the same subsystem.
It is worth quantifying because it is directly actionable: retention packages, handover periods and documentation requirements are all things that get negotiated before close. Discovering it afterwards means discovering it as a resignation.
Severity has to be separable from effort
A finding is only useful if the reader can decide what to do about it, and that needs two independent numbers: how bad it is, and what it costs to fix.
Those combine into three buckets that a deal team can act on:
Pre-close. Things that change the price or the terms. Licence incompatibility with the intended commercial model. A data protection obligation that is not being met. A dependency on something that cannot be transferred with the business.
First hundred days. Real problems with known fixes and predictable cost. An unsupported runtime with a migration path. Missing monitoring. A release process that requires a person at a keyboard on a Saturday.
Live with. Genuine imperfections that are cheaper to tolerate than to fix. Most codebases are mostly this, and saying so is part of the job. A report where everything is urgent is a report that has not prioritised.
What “we could not examine that” means
Diligence usually runs with restricted access, on a clock, in a competitive process. That is normal, and the correct response is to be explicit about it rather than to write around it.
If production infrastructure was not available, the report says so and says what that leaves uncertain. If only two of five engineers were made available for interview, that is recorded. If a subsystem was out of scope, that is stated plainly rather than being quietly omitted so the document reads as complete.
Unstated gaps are worse than stated ones, because the reader assumes coverage that does not exist and prices accordingly.
Things that are quietly expensive
A few findings recur often enough to be worth naming, and they are consistently underweighted relative to how much they cost later.
Data model problems. Code is comparatively cheap to change. A schema that has diverged from the business, or one where the same concept is represented three different ways, is expensive in a way that compounds and never announces itself as a single incident.
Nothing is reproducible. No infrastructure as code, no scripted environment setup, no reliable path from a clean machine to a running system. This slows every future engineer and makes disaster recovery theoretical.
Manual release. A deploy that needs a specific person following steps from memory is both a delivery constraint and a key-person dependency wearing a different hat.
Silent integration failures. Third-party integrations that fail without alerting. These are found by asking how the team learns an integration has broken. If the answer involves a customer, that is the finding.
Licences. Copyleft in a proprietary product is cheap to find during diligence and expensive to find during an acquisition two years later.
What a useful report looks like
Short. Findings ranked by severity, each with a plain statement of the problem, what it means commercially, an estimated remediation cost, and which of the three buckets it falls into. An explicit statement of scope and of what could not be examined. A summary somebody who is not technical can read and act on, with the detail available underneath for somebody who is.
And a clear answer to the actual question. If the system is sound, the report should say so briefly rather than manufacturing concerns to justify the fee. Diligence that never returns a clean verdict is not diligence, it is theatre, and the people commissioning it work this out quickly.
Independence is the whole product
The firm assessing a system should not be angling for the remediation work. The incentive is obvious and it corrupts the finding severity in a direction that is very hard to detect from outside.
If the assessment concludes that remediation is needed and the assessor wants that engagement, the honest move is to say so explicitly and let the buyer decide whether to take a second opinion. A report shaped by wanting the build that follows is worth nothing, regardless of how good the engineering analysis inside it is.