What technical due diligence actually checks

Most founders prepare for technical due diligence the way they'd prepare for a code review: tidy the repo, write some missing tests, hope the reviewer doesn't open the one file everyone's embarrassed by. That's the wrong preparation, because a diligence read isn't scoring code style — it's answering one question for the people writing the check: if this company grows 5–10× in the next 18 months, does the current system bend or break?

Here's what I actually look at, in the order I look at it, when I'm doing this for a VC or an acquirer.

1. Where the system already hurts

I ask engineering leadership directly: what broke in the last incident, and what did it teach you about the architecture? A team that can answer specifically — "our write path serializes through one table under load, we know it, here's the plan" — is in a fundamentally different position than a team that says "we've been pretty stable" with no specifics. The second answer usually means nobody's watching closely enough to know, not that nothing is wrong.

2. Whether the architecture matches the growth story

A seed-stage monolith serving 500 users is not a red flag. The same monolith, unchanged, while the deck promises 50,000 users in 12 months, is. I map the load-bearing parts of the system against the specific growth assumptions in the fundraising deck — not growth in general, the numbers actually being pitched — and flag where they diverge.

3. Bus factor on the parts that matter

Not "does everyone know everything" — that's an unreasonable bar for any team. The real question is narrower: for the two or three subsystems the whole product depends on, is there more than one person who could debug a production incident there at 2am? I've seen strong companies with a single point of failure in exactly one critical service, and it's fixable in a quarter once it's named. It's rarely fixable if nobody names it before the term sheet.

4. Data integrity and what "audit trail" actually means

Especially for anything touching payments, compliance, or regulated data: I check whether the audit trail is enforced at the data layer or just implied by application logic that a bug could silently skip. The difference matters enormously to an acquirer's legal and finance teams, and it's usually invisible from the outside until someone asks the direct question.

5. What the team optimized for under pressure

Every fast-moving team has cut corners — that's not the finding. The finding is which corners, and whether the team can name them unprompted. Teams that proactively surface their own debt ("we know X is fragile, here's why we made that call and what it'll cost to fix") are lower risk than teams that present a clean surface and let diligence discover the same issues independently.

What this is not

It's not a line-count audit, a linter report, or a test-coverage percentage treated as a verdict. Those numbers are inputs, not conclusions — 40% test coverage on a stable, well-isolated core can be a lower risk than 90% coverage on a system nobody trusts enough to refactor. I read the number in context, not instead of context.

If you're a founder heading into a raise or an acquisition conversation, the fastest way to de-risk this is the same fix that helps regardless of the deal: know your own answers to the five questions above before someone else asks them. See how a due diligence engagement is scoped.

Subscribe: RSS