The Founder's Guide to Technical Due Diligence

When a VC writes a check, they often hire someone like me to spend two days inside your codebase. This is what we look at, what gets a green light, and what gets a deal killed.

I do technical due diligence for VC funds. I've now done about thirty of these. The brief is usually: spend two days inside the codebase, talk to the engineering team, and write a memo for the partners. Should they invest? What's the risk profile?

If you're a founder raising a Series A or beyond, someone like me will probably be inside your repo. Here's what I look at, in the order I look.

Hour 1: Repo first impressions

I clone the main repo and run git log --oneline. I'm looking for:

• Commit cadence: regular commits over months, or bursts followed by silence?
• Author distribution: is one engineer responsible for 80% of the codebase? That's a key-person risk.
• Commit message quality: do they tell me what changed, or just say "fix" 400 times?

I also check the README. Is there one? Can I get the project running locally with the instructions? If I can't get it running in 30 minutes, that's a signal about the team's empathy for new contributors.

Hour 2-3: Architecture walkthrough

I ask the CTO to walk me through the architecture on a whiteboard. I'm not testing whether they know their architecture. I'm testing:

• Can they explain it in 15 minutes to a stranger? If they can't, neither can the next senior hire.
• Do they know the failure modes? I ask "what happens when X is down" three or four times. The good ones answer immediately. The shaky ones go quiet.
• What's been removed lately? Architecture that only grows is architecture that's accumulating debt.

Hour 4-6: Code reading

I pick three files at random and read them. I'm looking for:

• Test coverage on critical paths, not overall coverage numbers.
• The shape of error handling: are exceptions caught and logged, or silently swallowed?
• Comments: not how many, but do they explain why rather than what.
• Consistency: does the codebase have a recognizable style, or is every file written by a different person on a different day?

I also look at the auth code specifically. The first auth-related antipattern usually correlates with five more.

Hour 7-9: Operations

I pull up Datadog, CloudWatch, or whatever they use. I'm looking for:

• p95 and p99 latency: not just averages.
• Error rate trends: stable, climbing, or noisy?
• Deploy cadence: how often do they ship? Daily is healthy. Monthly is a sign of fear.
• On-call: who's on it? How often does it page?

I ask to see the most recent post-mortem. If they don't have post-mortems, that tells me about the maturity of the org.

Hour 10-12: The team conversation

I talk to two engineers without the CTO in the room. I ask:

• What part of the codebase are you afraid of? Every codebase has one. I want to hear which one.
• If you could rewrite one thing, what would it be? This tells me what they think is broken.
• What's the tenure trend? Has the senior team been here long, or are they all new?

The best signal is whether engineers feel comfortable being honest. The worst signal is rehearsed answers.

What gets a green light

I write a green-light memo when I see:

• A clean main service with sane structure.
• Working CI with real tests, run on every PR.
• Observability that the team actually uses (not just installed).
• An on-call rotation with documented playbooks.
• A CTO who can name three risks without prompting.

That's all. No magic. Just basic engineering hygiene applied consistently.

What gets a red flag

I red-flag when I see:

• Hardcoded credentials anywhere in the repo, even in tests.
• A primary database with no backup verification process.
• A founder-only commit graph (single point of failure on the team).
• Architecture I can't explain to a partner in three sentences.
• Test coverage on critical money paths under 30%.
• A custom auth system with no external review.

A single one of these doesn't kill a deal. Three of them in combination usually do.

What founders should do before they're audited

• Run a self-audit two months before raising. Hire someone to do the diligence on you, before someone does it to you.
• Document your architecture. A simple README and an ADR folder go a long way.
• Clean up the obvious smells. Hardcoded credentials, dead code, unused services. Diligence is shallow. Surface matters.
• Know your numbers. p95 latency, error rate, deploy frequency, MTTR. If you can recite these, you sound like an operator.

The sharper insight

The diligence reviewer is reading the team, not the code. I've green-lit codebases that were objectively messy because the team showed self-awareness, ownership, and a clear plan. I've red-flagged immaculate codebases that were maintained by a team that couldn't explain their own decisions. The deal is on the people. The code is just a window into how they work together.

If you're a founder thinking about raising and want a friendly pre-audit, that's exactly the work I do. It's much cheaper to fix things before a real diligence reviewer sees them.

References

• Mark Suster on technical diligence
• The Pragmatic Engineer on engineering org diligence
• Y Combinator due diligence guide