Technical due diligence for early-stage investors

VCs ask me to do technical due diligence on startups they're considering investing in. The question is always the same: "Can this team actually build what they're promising?"

After doing this for a few years, I've learned that the answer rarely comes from the technology stack or lines of code. It comes from understanding how the team works, what trade-offs they've made, and whether those trade-offs make sense for where they are.

What I actually look for

Here's what matters when evaluating a technical team at seed or Series A:

1. Can they ship?

Look at their git history. How often do they deploy? How many features have they shipped in the last three months? Are they iterating quickly or stuck in endless refactoring cycles?

Red flags: Lots of branches that never get merged. Deployments happening once a month. The words "we're planning a big rewrite."

2. Do they understand their own system?

Ask the CTO or lead engineer to walk you through their architecture. Can they explain it clearly? Do they know where the bottlenecks are? Can they tell you what breaks when traffic spikes?

Good teams know exactly what's fragile and why. They can tell you "the payment processing queue backs up sometimes but we have monitoring on it." Bad teams wave their hands and say "it's all microservices on Kubernetes" without understanding what that actually means.

3. Are they over-engineering or under-engineering?

Early-stage startups need to move fast. If they're running 15 microservices for 100 users, that's a problem. If they have zero tests and deploy by sshing into servers and running git pull, that's also a problem.

Look for: Automated deployments, basic test coverage, monitoring that actually gets looked at, and infrastructure that's simple enough for the team to understand.

4. Can this team scale with the company?

This is the hard question. Will the founding engineers still be effective when the company is 50 people? Can they hire? Do they document things? Can they explain technical concepts to non-technical co-founders?

Talk to the team. If they're all doing everything and nobody owns anything, that's a scaling problem waiting to happen.

My checklist

Here's what I actually check:

• Deployment frequency: Daily is great, weekly is fine, monthly is a red flag.
• Test coverage: Not looking for 100%, but there should be tests for critical paths.
• Monitoring and alerts: Do they know when things break? Do they have dashboards they actually look at?
• Documentation: Is there a README that explains how to run the app? Can a new developer get set up in under an hour?
• Code quality: Not looking for perfection, but is the code readable? Can you follow what's happening?
• Technical debt: Do they know where it is? Do they have a plan for managing it?
• Security basics: HTTPS? Environment variables for secrets? Any basic security hygiene?

Red flags that make me walk away

1. The CTO can't explain the architecture. If the technical leader doesn't understand their own system, nobody does.
2. No version control or chaotic git history. This means they don't have a development process.
3. They're planning a complete rewrite. This usually means they've lost control of the codebase.
4. The team can't ship without the founder. Single point of failure.
5. Zero monitoring or error tracking. They're flying blind.

Green flags that make me optimistic

• They ship regularly. The git log shows consistent progress.
• They know what's broken. They can tell you exactly what technical debt they're carrying and why.
• The technology choices make sense. Not "modern" but "appropriate for a team of three engineers."
• They have basic observability. They can answer "what's slow?" and "what's breaking?"
• The team can explain trade-offs. "We're not doing X because we need to ship Y first" shows good prioritization.

Need technical due diligence for a potential investment? We review codebases, interview technical teams, and provide detailed reports for VCs and acquirers. Get in touch.