Technical due diligence is not a code review. Nobody’s going to nitpick your variable names. They’re checking whether the thing they’re about to buy or fund can survive contact with reality without you. Here’s what actually gets looked at.

What they’re really checking

Three questions drive almost every technical DD: can this keep running without the founder, is the cost structure sane at 10x current scale, and is there a landmine (security, licensing, compliance) that turns into a lawsuit later. Everything on the checklist maps back to one of those three.

The bus-factor question

If one person can explain the whole architecture from memory and nobody else can deploy a fix without them, that’s the single biggest red flag in a small-company DD. You can’t fix this in the two weeks before diligence starts, but you can make it look less bad:

• Write down the deploy process, even roughly, in a RUNBOOK.md. A diligence team reading “here’s how we ship” is reassured even if the process is manual.
• Make sure at least one other person on the team has actually run it, not just read about it.
• Document the “if the founder disappears tomorrow” scenarios: where are the secrets, who has domain/DNS/cloud account access, is there a second admin on every critical service.

Cost structure at scale

They will ask what your infrastructure costs at current usage, and then ask what it costs at 10x. If you don’t have an answer, that’s worse than a bad answer. Know your per-user or per-request cost, and know which line items scale linearly versus which ones are fixed and will stay flat as you grow. A cloud bill that’s 90% one oversized reserved instance you’ve been meaning to right-size is an easy fix — flag it and fix it before someone else finds it.

Security and compliance landmines

These are the findings that kill deals, not just discount them:

• Secrets committed to git history, even if rotated since. Check with git log --all -p | grep -iE 'api[_-]?key|secret|password' across the whole history, not just HEAD — a rotated key still shows you had the habit.
• No access logging on who touched customer data.
• Dependencies with known CVEs that haven’t been patched. Run your dependency scanner (npm audit, pip-audit, whatever fits your stack) and actually clear the high-severity findings, don’t just note them.
• Data residency or licensing issues — GPL code shipped inside a closed product, customer data stored somewhere your contract with that customer doesn’t allow.

Fix what you can find in the weeks you have. For anything you can’t fix in time, write it down yourself with a remediation plan. A known issue with a plan reads completely differently from the same issue discovered by their team.

What to have ready before anyone asks

• Architecture diagram, even a hand-drawn one exported to PDF. It saves an hour of them reverse-engineering your system from code.
• A list of every third-party service and API you depend on, with what breaks if each one goes down.
• Your actual uptime history if you track it, or an honest description of your incident history if you don’t.
• Test coverage numbers, and be honest about what’s actually covered versus what’s just counted.

The gotcha

The worst outcome in DD isn’t finding a problem — every codebase has problems, and experienced diligence teams expect that. The worst outcome is a problem you didn’t know about and can’t explain, because now they’re wondering what else you don’t know. Do your own pass with fresh eyes (or better, someone else’s) before theirs starts. Surprising yourself first is much cheaper than surprising them.

---