← Back to Insights

What Technical Due Diligence Usually Misses

Most technical due diligence checks whether the code works today. It rarely checks what it will cost to keep working.

A typical technical due diligence pass looks at architecture diagrams, runs through a security checklist, samples some code for obvious red flags, and interviews the engineering lead. All of that is necessary. None of it answers the question an acquirer actually cares about: what does this technology cost to own for the next three years, and what's the probability that cost is dramatically higher than it looks today?

The gap between "it works" and "it's sound"

A codebase can pass every item on a standard checklist — recent commits, reasonable test coverage, no glaring security holes — and still be sitting on a foundation that makes the next eighteen months of roadmap far more expensive than the deal model assumes. The checklist tells you the house isn't on fire today. It doesn't tell you what's load-bearing, what's held together with undocumented tribal knowledge, or what breaks the moment the one engineer who understands it leaves — which, post-acquisition, is exactly when that engineer is most likely to leave.

Four things a scorecard needs to actually catch

• Key-person concentration. Which systems have exactly one person who genuinely understands them, and what does replacing that knowledge cost if they don't stay through the transition? This is routinely the single biggest hidden liability in a technical acquisition and routinely the least examined.
• Vendor and platform lock-in. Not just "what's the AWS bill," but which architectural decisions would be expensive or slow to unwind if the acquirer's own platform strategy doesn't match the target's. A dependency that's invisible in a demo can be a multi-quarter migration project post-close.
• The shape of the technical debt, not just its existence. Every codebase has technical debt; that's not the finding. The finding is whether the debt is contained and well-understood, or load-bearing and compounding — those require completely different remediation budgets, and a surface-level review can't tell them apart.
• Whether the team can actually ship the acquirer's roadmap. A team well-suited to maintaining what exists isn't automatically well-suited to the integration work or new build the acquisition is meant to unlock. This is a delivery-capability question, not just a code-quality one, and it's usually the one most conspicuously absent from the report.

Why this matters more with AI-built or AI-assisted codebases

As more target companies ship code with heavy AI assistance, a new diligence question is emerging alongside the old ones: was the AI-generated code reviewed with the same rigour as human-written code, or did velocity outpace verification? Fast output is not evidence of quality either way — it can just as easily mean disciplined AI-native delivery or a codebase where nobody was checking the model's work closely enough. Distinguishing the two requires actually looking, not assuming.