At some point someone will pay a person like us to look at your technology before money changes hands — a Series A with a thorough lead, an acquisition, a PE platform deal. Founders imagine this as a code review and panic about their variable names. Wrong mental model. Nobody's grading your code style.
Diligence answers one question: does the technology support the story being sold? Here's how that actually breaks down.
What we're actually evaluating
Does the architecture survive the plan? If the deck says 10x users in two years, we're looking for what breaks first, and whether it's a known, budgeted problem or a surprise. Every system has a ceiling — mature teams know where theirs is.
Key-person risk. How much of the system lives in one head? What's documented versus tribal? If the lead engineer leaves the Friday after close, what happens Monday? This kills more deals than bad code ever has.
The security floor. Not "is it perfect" — "is it responsible." Secrets management, access control, dependency hygiene, what data is stored where, and whether anything already leaked. One hardcoded production credential in the repo history changes the tenor of everything after.
Velocity, verified. The roadmap implies a shipping pace. Git history, deploy frequency, and incident patterns tell us the actual pace. The gap between claimed and actual velocity is the single most common finding.
Honest debt versus hidden debt. Every codebase has debt. Teams that know their debt — where it is, why it's there, what it costs — read as competent. Debt the team doesn't know about, or won't say out loud, reads as risk. Same debt, different valuation impact.
Ownership, licensing, and the AI question. Does the company actually own what it's selling? Contractor IP assignments, GPL contamination, and — new since the AI era — whether anyone can articulate what was generated, from what, under what terms. Messy answers here don't usually kill deals; they delay closes and fund escrows.
How it actually goes down
A real diligence is short: reading access, a few hours of architecture walkthrough, conversations with whoever runs engineering, and — this part matters — listening for how the team talks about its own system. Confident specificity ("that module's fragile, here's the containment plan") is the good sound. Hedging, surprise, or engineers contradicting each other about how things work is the bad sound. We can't audit every line and we don't need to; the team's relationship with its own technology is the highest-signal artifact in the room.
How to be ready (start two quarters early)
- Write the architecture down — one page, current, honest. The doc existing matters almost as much as its contents.
- Fix the floor: secrets out of the repo, access controls reviewed, dependency updates running. Cheap now, expensive under deadline.
- Keep a debt register. The two-column version is fine: what's ugly, why it's rational. It converts your worst diligence findings into evidence of competence.
- Know your numbers: deploy frequency, incident count, time-to-restore. Approximate is fine. Blank stares are not.
- Run a mock diligence. An independent read six months before the real one finds the problems while they're still yours to fix quietly. (This is a thing we do — it's the Diagnostic engagement — but even an experienced friend with fresh eyes beats nothing.)
The companies that sail through diligence aren't the ones with pristine code. They're the ones with no surprises — where everything the reviewer finds, the team already knew and could explain. That's the entire game. Play it early.