What We Look for in Technical Due Diligence
We regularly advise investors on technical due diligence for startups raising Series A and beyond. Over dozens of assessments, we've learned that the things that matter most aren't always the things founders expect.
What Matters More Than You Think
Deployment pipeline maturity. Can the team ship a bug fix to production in under an hour? Do they have automated tests that run on every commit? A mature deployment pipeline is the single best indicator of engineering culture. It tells you the team values reliability, can iterate quickly, and has invested in their own productivity.
Error handling and logging. We look at how the application handles failures. Are errors caught and logged with context? Is there alerting? Can the team reconstruct what happened when something goes wrong? Teams that handle errors well build reliable systems.
Data model clarity. A clean, well-normalized data model tells us the team thought carefully about their domain before writing code. A messy data model, with redundant fields, unclear relationships, and no documentation, is a leading indicator of future technical debt.
What Matters Less Than You Think
Technology choices. Rails vs Django vs Express doesn't matter much. What matters is whether the team chose a technology they know well and can hire for. The "best" technology is the one your team can execute with.
Code style and formatting. As long as there's a linter and it's enforced in CI, the specific style rules are irrelevant. We're looking for consistency, not taste.
Test coverage percentage. A project with 40% coverage of critical paths is better than one with 90% coverage of trivial getters and setters. We look at what's tested, not how much.
Red Flags
The real red flags are: no version control or messy commit history, secrets hardcoded in the codebase, no staging environment, manual deployments, and knowledge silos where only one person can deploy or debug critical systems.
Summary
Technical due diligence isn't about finding the perfect codebase. It is about assessing whether the engineering team can scale. The codebase is a window into how the team thinks, communicates, and prioritizes.