Technology due diligence has a persistent habit of stopping at the architecture diagram. An advisor reviews the documented stack, checks it against current best practice, produces a slide rating it green or amber, and the deal proceeds on the assumption that a reasonable-looking architecture equals reasonable technology risk. This is one of the more expensive assumptions in modern dealmaking.
Architecture diagrams describe intent. They are drawn by people with every incentive to present the system in its best light, updated inconsistently, and almost never reflect the accumulated shortcuts, the undocumented dependencies and the fragile integrations that actually determine how expensive the system will be to operate and extend after the deal closes. Real diligence starts where the diagram ends.
The team matters more than the stack
Technology is operated and evolved by people, and the people risk in a target company is frequently larger than the technical risk, yet it receives a fraction of the diligence attention. Who actually understands the critical systems, how concentrated that understanding is in one or two individuals, and what their retention risk looks like post acquisition are questions that belong at the centre of the assessment, not the margins.
A well-architected system maintained by a thin, flight-risk team is a worse acquisition than an unglamorous system maintained by a deep, stable one. Diligence that does not interview the engineering team directly, rather than relying entirely on management's account of it, misses this distinction almost every time.
The architecture diagram tells you what the system was designed to be. The team, the delivery record and the debt tell you what it actually is.
The delivery record predicts the future better than the roadmap does
A target's roadmap describes what management intends to build. Its delivery record, how reliably past commitments were met, how often releases slipped, how incidents were handled, describes what the organisation is actually capable of executing. Buyers who diligence the roadmap and skip the delivery record are pricing the deal on aspiration rather than evidence.
This requires going past the management presentation and into ticketing systems, incident logs and release history where available, looking for the pattern of commitments made against commitments kept over a meaningful period, not a curated quarter chosen to look good.
Technical debt is a number, not a vibe
Every target has technical debt; the diligence question is whether it is understood, quantified and manageable, or unknown, unquantified and compounding. A target that can produce a credible inventory of its debt, with an honest view of what it will cost to address and what happens if it is not addressed, is in a fundamentally different risk category from one that cannot, regardless of which one currently looks more polished in the data room.
Where the target genuinely does not know the scale of its own debt, that itself is the finding: it indicates an engineering organisation that has not been given the space or incentive to track its own liabilities, which tends to correlate with other forms of under-governed risk.
- 路Interview engineering leadership and a sample of individual contributors separately from commercial management
- 路Request incident history and release cadence data, not just a description of the deployment process
- 路Map key person dependency explicitly: which systems have a single point of understanding and what retention terms cover those people
- 路Require a debt inventory with cost-to-fix estimates, not a general assurance that debt is manageable
The post deal plan has to exist before the deal closes
Findings that surface during diligence and then sit in a report nobody actions after signing are worse than not having found them, because they create false confidence that the risk was handled. Every material finding should convert into a specific first-hundred-days action with an owner, whether that is a retention package for a key engineer, a remediation budget for critical debt, or a defined integration plan for systems that will need to merge.
The value of good diligence is not the report; it is the plan the report makes possible. Buyers who treat diligence as a gate to close the deal, rather than as the input to what happens immediately after, tend to rediscover the same risks eighteen months later at a much higher cost to fix.
Good technology due diligence is uncomfortable in a way that a clean architecture review is not, because it requires talking to people who did not prepare a slide, reading logs nobody curated, and putting a number on problems that management would rather describe qualitatively. That discomfort is exactly where the useful information lives.
Deals do not fail because the architecture diagram was wrong. They fail because the team left, the delivery record was worse than represented, and the debt turned out to be a multiple of the estimate nobody asked for. All three of those are knowable before the deal closes, if diligence is willing to look past the diagram.