Technical due diligence checklist for startup deals

Technical due diligence has one job: find the gap between what a company believes about its technology and what is true, before the money moves. I run these assessments on real deals — this is the checklist, organized the way I actually work it, with the questions that surface what a well-prepared data room is designed to smooth over.

1. Code and architecture: does reality match the deck?

• Repository history tells the staffing story: who really wrote this, over what period, with what continuity. A "team of eight" whose commits come from two accounts is a finding.
• Architecture vs. claims: "AI-powered platform" and "scalable microservices" get verified at the code level, not the diagram level. The gap between pitch vocabulary and repository reality prices deals.
• The load-bearing components get read closely; everything else gets sampled. Depth where money flows, breadth everywhere else.
• Third-party dependence: which capabilities are actually thin wrappers over vendors, and what happens to margins and moats when a vendor reprices.

2. Reproducibility: can this system be rebuilt?

• Fresh clone → running system, using only the repository and its documentation. Failure here is the single most predictive finding in my experience: systems that cannot be rebuilt cannot be safely changed.
• Database schema from migrations, not from a hand-tended production instance nobody dares touch.
• Deploys: automated and promotable, or a person with SSH and courage? Key-person risk lives here more often than in any org chart.

3. Security and data posture

• Secrets scan across full git history — committed credentials survive deletion and surface in escrow reviews at the worst moments.
• Authorization enforced at the API layer, verified by attempting what the UI forbids (the same checks that catch AI-built apps catch everyone else).
• PII mapping against stated privacy posture; log and analytics leakage; data-deletion reality vs. policy.

4. Payment and revenue integrity

• Revenue metrics reconciled against processor records — MRR dashboards and settlement data disagree more often than buyers expect, and the direction of the disagreement matters.
• Billing edge cases that cost real money: webhook idempotency, refund and dispute unwinding, dunning state, ledger integrity where balances exist.
• Whether the subscription base could survive a provider migration — an acquirer integrating payments needs to know before pricing the integration.

5. Team and process: will shipping survive the deal?

• Bus factor per critical system, measured from history, not interviews.
• Tests and CI as practiced culture vs. installed decoration — the difference is visible in whether tests fail when code breaks.
• What the team says vs. what the repository says about velocity, and which one the earn-out assumptions were built on.

Reading the findings

Every finding lands in the same frame I use for independent reviews: severity, classification (salvage, fix, rebuild, defer), and the challenge to put to the team — because DD findings are negotiation material, and negotiation needs evidence, not vibes. The pattern across findings is the real deliverable: a company that knows its own weaknesses is a different purchase than one that is surprised by them.

Frequently asked questions