Tous les articles

A technical due diligence checklist that fits a deal window

A technical due diligence checklist is only useful if it fits inside a deal. Most published ones do not: they list two hundred items of equal weight, which in a three-week window means either skimming everything or auditing the first half and running out of time before the part that mattered.

Ours is ordered by a single criterion: what can change the deal, meaning the price, the terms, the retention clauses, or the decision itself. Everything else is context. This is the checklist as we run it, section by section, with a note at the end on what to cut when the window is short.

How this technical due diligence checklist is ordered

Deal-changing findings cluster in a few places: systems that cannot support the growth being underwritten, security exposure with liability attached, knowledge concentrated in one or two heads, and claims that do not survive verification. So we spend the first days where those live, and we treat the rest as supporting evidence. A good technical data room speeds this up considerably; a thin one is itself a finding.

Architecture, code, and delivery

  • Does the architecture support the growth plan in the model, at 3x and at 10x
  • Where are the bottlenecks: database, queues, third-party rate limits, single-tenant assumptions
  • What does infrastructure cost per customer today, and how does that curve bend at scale
  • Is there a rewrite hiding in the roadmap, and has anyone costed it
  • How much of the stack is vendor-locked, and what would migration cost

Elegance is beside the point here, and plenty of ugly architectures print money. The question is whether the plan you are paying for runs on this system without a rebuild nobody has budgeted. Then move from the structure to the way the team ships:

  • Test coverage where it matters: the billing path, the data path, the core domain logic
  • Review discipline: are changes reviewed, by whom, with what rigor
  • Commit history as a delivery record: velocity, bus factor, who touches the critical modules
  • Dependency health: how far behind, and what is unmaintained versus merely old
  • Deployment: how code reaches production, how fast a bad release can be rolled back

Read the code, but read the history harder. Two years of commits tell you how the team ships under pressure, which no interview will. License hygiene rides along with dependency health: most findings are noise, and the few copyleft cases that matter are covered in the open source license review.

Security and compliance

  • Secrets: are credentials in the repo, in CI logs, in old commits
  • Access control: who can reach production data, and is offboarding real
  • Incident history: what broke, who found out, what changed afterwards
  • Data handling: GDPR mapping, processor agreements, deletion that deletes
  • Certifications: what SOC 2 or ISO 27001 covers here, if present

Scope this to the deal window rather than running a full penetration test; we cover how in security due diligence that fits a deal window. The goal is to find the findings that stall deals: exposed customer data, secrets in public history, compliance claims contradicted by the infrastructure. Certifications deserve a careful read rather than a tick, since what SOC 2 proves is narrower than the badge suggests.

Team and knowledge

  • Who can rebuild each critical system, and how many names appear once
  • What leaves with the top two engineers, concretely
  • Hiring plan versus the roadmap: which roadmap items depend on people not yet hired
  • How decisions get made: is there engineering leadership or one exhausted founder

An hour with the CTO is worth a day in the data room here. We run that conversation as a structured session, described in the CTO interview, because how someone talks about failures tells you more than the architecture diagram.

The AI layer

If the target claims AI, the checklist grows: production reality behind the demo, evaluation practice, unit economics of inference, data rights, model provider dependency. That list is long enough to be its own note, and it is: the AI due diligence checklist we use on live deals. The short version: verify the AI on real traffic and real margins rather than on the demo, because the distance between the two is where AI deals go wrong.

What to skip when the window is short

With 3 to 4 days instead of weeks, cut in this order. Skip full dependency audits: sample the critical services. Skip line-by-line code review: read the two modules the business depends on and the commit history of everything else. Skip process archaeology: one deployment walkthrough shows you the delivery reality. Do not skip: secrets scanning, access control, the scalability question against the actual growth plan, the team map, and AI claim verification. Those are cheap to check and expensive to miss.

Severity ranking never gets cut. Ten findings without a ranking are noise; three findings translated into money and time are a report an investment committee can act on, and reading that report well is a skill of its own.

If you would rather have the checklist run by people who do this every week, our technical due diligence practice covers this scope, from a 3 to 4 day focused read to a 2 to 3 week full audit, with a scorecard and a severity-ranked risk register as the output.