What does technical due diligence actually check?

Buyers assume technical diligence is a code review with a deadline. It is not, and the reports that read like one miss the risks that actually reprice deals. Code quality is a maintenance cost, and maintenance costs are knowable and financeable. What diligence exists to find is different in kind: the risks that are binary, human, or contractual.

What actually moves the price?

Key-person concentration, first and always. We ask for the commit graph, the deploy permissions and the on-call history, then ask quietly: if these two people leave in the twelve months after close (and retention math says one will), what stops working? Companies routinely carry systems only one head understands, and a purchase agreement does not transfer what is in the head.

Standing obligations, second. The enterprise contract that promises four nines nobody priced; the customer whose integration freezes an API in amber; the data residency clause signed during a different architecture. And the licensing stratum: the copyleft dependency in the proprietary core, the vendor whose terms changed and whose renewal now holds the cards. None of this is visible in the code. All of it is visible in the contracts folder, read next to the architecture.

Third, the distance between the story and the system. Every seller has a narrative ("cloud-native platform, AI-driven, infinitely scalable"). The diligence method is the auditor's, not the critic's: generate the picture from evidence (infra bills, traffic data, deploy logs, the actual load path) and diff it against the deck. Small diffs are normal commerce. Large diffs are the finding, whatever direction they run; we have twice found systems better than their story, which repriced the deal the pleasant way.

What do the artifacts confess under fan-out?

The four we weight heaviest, in order of candor: the incident folder (physics), the infrastructure bill (architecture in dollars: a bill dominated by one heroic database says fragility without a diagram), the dependency manifest (each pinned five-year-old version is a deferred project), and the offboarding doc for the last senior departure, whose thoroughness measures how much knowledge the org can actually externalize.

What would we have a seller do?

The same things, a year early, because every finding above is cheaper to fix than to discount. Write the decision records now; a buyer's engineers relax visibly in a data room with dated reasoning in it. Break the key-person monopoly with understudy rotations. Reconcile the deck with the system before someone is paid to do it adversarially.

Diligence, done properly, is just an architecture review with money attached and no politeness budget. The systems that pass well are not the elegant ones. They are the ones whose owners can answer "what would have to be true" questions without checking who is in the room.