Technical Due Diligence for M&A: What We Actually Check in Four Weeks

Technical due diligence gets commissioned the way legal and financial diligence do, but it's frequently scoped like a code quality audit, which is close to useless for the actual purpose. Acquirers don't need to know whether the target's code style is consistent — they need to know whether the platform can survive a 3x traffic increase post-acquisition, whether it's carrying undisclosed security exposure, and whether the two or three engineers who understand the core system are flight risks. Those are the findings that move deal terms.

Read the incident history before the codebase

The single highest-signal artifact in a DD engagement is the incident and on-call history, not the source tree. A platform with a thin incident log either has genuinely excellent reliability engineering or — far more often — isn't tracking incidents at all, which is itself a finding. We ask for the last twelve months of postmortems, or the raw incident tickets if postmortems don't exist, and look specifically for repeat incidents against the same subsystem, which indicates a structural problem the team has been patching rather than fixing. A target that's had the same database contention issue cause three separate outages in a year has a scaling ceiling that will matter within the first year of integration, well before most other findings would surface.

Bus factor is a finding, not a footnote

We map, by name, who has production access, who has ever deployed the core billing or auth systems, and who wrote the pieces of infrastructure with no documentation and no tests. In more engagements than we'd like, this map produces one or two names carrying disproportionate institutional knowledge with no succession plan — information that belongs in the deal memo alongside any other key-person risk, because losing that person during or shortly after close is a realistic scenario, not a hypothetical one. This is a people finding surfaced through technical means, and it changes retention negotiations more often than any code-quality finding does.

Security exposure gets verified, not asked about

We don't accept a target's self-reported security posture — we verify the specific claims that matter for a deal: whether authentication and authorization checks are enforced server-side (a distressing number of platforms trust client-side role checks for at least one privileged action), whether secrets are actually rotated on the schedule the security policy claims, and whether the dependency tree has known critical CVEs sitting unpatched in production. We've found unpatched remote-code-execution-class vulnerabilities in production dependencies during roughly a third of the engagements we've run in the past two years — this is common enough that we treat "we haven't found anything yet" as a reason to look harder, not a sign the target is clean.

Infrastructure cost is a scaling forecast, not a line item

Acquirers usually diligence infrastructure spend as a current-state cost line, but the number that actually matters is the marginal cost curve — what happens to infrastructure spend as usage scales toward the acquirer's growth projections, not the target's historical trajectory. A platform architected around a per-tenant database model has a very different cost curve under 10x growth than one on shared infrastructure, and that curve belongs in the financial model, not just the technical appendix.

What a good DD report tells the acquirer to do next

The deliverable that's actually useful isn't a findings list scored red/yellow/green — it's a prioritized set of "do this in the first 90 days post-close" actions, because that's what the integration team will actually execute against. We rank findings by how much they change either deal terms (walk-away issues, price adjustments) or the day-one integration plan (systems that need immediate hardening before they can bear increased load), and we're explicit about which findings are neither — interesting to know, but not worth spending integration-team attention on in the critical early window.