Technical due diligence kills more deals than people realize. Not because the technology is bad — usually it is fine. Because the founder cannot answer questions about it under pressure, and the investor concludes there is hidden risk.
This post covers the 8 areas tech DD teams actually check, what good looks like on each, and what to prepare in advance to avoid the awkward "let me get back to you" loop.
Area 1: Architecture Documentation
DD opens with: "Walk me through your architecture." If you reach for the whiteboard and start drawing from memory, you have already lost trust. The expected answer is "here is our architecture doc" with a link to a Notion page or a /docs/architecture.md.
What good architecture doc looks like
- One-page system diagram: services, databases, queues, external dependencies. Updated within the last 90 days.
- Per-service one-pagers: what it does, who owns it, how it scales, what depends on it.
- Data flow diagrams for critical user flows (signup, payment, core feature).
- Decision log: major architecture decisions (e.g., why Postgres vs MongoDB, why monolith vs microservices) with rationale.
If you do not have these, spend 2 weeks writing them before any DD. Investors read them, take them seriously, and the prep work clarifies your own thinking.
Area 2: Test Coverage
Coverage % matters less than where the coverage is. 100% coverage of trivial getters/setters and 0% coverage of payment logic is worse than 50% coverage focused on business logic.
What DD teams check
- Overall line coverage: 60%+ is healthy. Below 30% is a red flag.
- Coverage of critical paths: payments, auth, billing — should be 80%+.
- CI runs tests on every commit: not "we run tests sometimes."
- Test reliability: flaky tests indicate process issues. CI green rate should be 95%+.
How to prepare
Before DD, run coverage report. If under 30%, write tests for top 5 critical paths over 2-3 weeks. Going from 30% to 50% with focused critical-path coverage is more valuable than going from 50% to 80% with low-value coverage.
Area 3: Dependency Audit
What third-party libraries do you depend on? Are they maintained? Are there known CVEs? What licenses?
The four checks
- Dependency freshness: when was your package-lock / Gemfile.lock / Pipfile last touched? Over 6 months is a yellow flag. Over 12 months is red.
- Known vulnerabilities: run npm audit / pip-audit / dependabot. Critical CVEs unresolved for over 30 days are a red flag.
- Abandoned dependencies: any dependency without a commit in 18 months should be flagged. Migration plan or replacement option.
- License compatibility: GPL-licensed dependencies in proprietary code can create acquisition blockers. Audit licenses, document.
Area 4: Infrastructure Cost vs Scale
What does your infrastructure cost vs what does it serve? DD teams calculate cost per user, cost per €1 of revenue, cost per transaction. Outliers get scrutinized.
What good looks like
- Infrastructure cost as % of revenue: SaaS healthy is 5-15%. Below 5% is exceptional. Above 25% is structural problem.
- Cost growth rate vs user growth rate: ratio above 1 means costs growing faster than users. Bad sign.
- Single-tenant vs multi-tenant: if every customer has their own infrastructure, costs scale linearly. Multi-tenant scales sub-linearly.
What to prepare
One-page summary: monthly infrastructure spend by provider (AWS, Vercel, etc.), broken down by service category. Trend over 12 months. Cost per active user metric.
Area 5: Bus Factor
Bus factor = number of engineers who could be hit by a bus before the project becomes unmaintainable. Investors ask: "If [key engineer] left tomorrow, what would break?"
How to assess your own bus factor
- For each critical system, who can debug it? If only one person, bus factor = 1.
- For each deployment, who can do it? Same question.
- For each external integration, who knows the credentials, the contract, the SLA?
How to improve
- Pair programming on critical systems. Two people learn each system minimum.
- Runbook for every recurring operation. Someone unfamiliar should be able to execute from the runbook.
- Rotate on-call. Forces knowledge spread.
- Document architecture decisions in writing. Tribal knowledge dies with the person.
Area 6: Deployment Frequency
How often do you deploy to production? This single metric reveals engineering maturity.
What DD teams expect
- Multiple deploys per day: elite. Indicates strong CI/CD, good test coverage, blameless culture.
- Deploy per day: healthy. Most successful startups land here.
- Deploy per week: acceptable but indicates friction.
- Deploy per month or less: red flag. Indicates batch releases, high deploy risk, weak testing.
Why it matters
Deploy frequency correlates strongly with engineering velocity. Low deploy frequency means features ship slowly, fixes take longer, and the engineering culture has friction.
Area 7: Incident History
Investors will ask: "What is your worst incident in the last 12 months? Walk me through it."
The expected answer is honest, specific, and shows learning. "We had a database outage on March 14 for 45 minutes. Root cause: missing index on a query that became slow as data grew. Fix: added index, set up query monitoring alerts. Post-mortem in /docs/incidents/2026-03-14.md."
What to prepare
- Incident log: every incident in the last 12 months, with date, duration, root cause, resolution.
- MTTR (mean time to recovery): average time from incident start to resolution.
- Top 3 incidents post-mortemed: written documents, blameless, focused on systemic causes.
- Trend: incidents per month decreasing or stable? Increasing = process problem.
Area 8: Team Structure
How is the engineering team organized? How do decisions get made? Where are the bottlenecks?
What DD teams look at
- Engineering org chart: who reports to whom, span of control, current open roles.
- Decision-making process: architecture decisions, prioritization, hiring — who decides?
- Tenure distribution: all <1 year is risk. All 5+ year is stagnation risk. Mix is healthy.
- Hiring funnel: can you hire? Time-to-hire under 90 days is healthy.
- Retention: annual engineering attrition. Under 10% is healthy. Above 20% is red flag.
The 8 Areas Summary
| Area | What good looks like | Prep time before DD |
|---|---|---|
| Architecture docs | One-page diagram, per-service docs, decision log | 2 weeks if missing |
| Test coverage | 60%+ overall, 80%+ critical paths | 2-4 weeks if low |
| Dependency audit | Updated, no unresolved CVEs, license clean | 1 week |
| Infrastructure cost | 5-15% of revenue, sub-linear scaling | 1 week |
| Bus factor | 3+ on every critical system | 1-2 months ongoing |
| Deployment frequency | Daily or better | 3-6 months to improve |
| Incident history | Logged, post-mortemed, declining trend | 1 week if missing log |
| Team structure | Clear org, low attrition, healthy hiring | Ongoing |
The 30-Day DD Prep Sprint
If you have a fundraise coming and have not prepared:
- Week 1: write architecture docs, create incident log, run dependency audit.
- Week 2: write top 5 post-mortems if missing, calculate test coverage and identify gaps.
- Week 3: patch CVEs, update stale dependencies, document decisions.
- Week 4: mock DD interview with your CTO + a friendly external advisor. Identify weak answers, prepare better ones.
What DD Cannot Hide
DD can clean up surface presentation. It cannot fix:
- An engineering culture that does not deploy often (months to fix).
- A single engineer who knows all the critical systems (months to spread knowledge).
- Tech debt that requires rewrites (years sometimes).
- A team that cannot hire (structural problem).
These are the things investors discover by talking to your engineers, not by reading your docs. Prepare the docs and prepare the team.
Red Flags That Kill Deals
- Founder cannot explain architecture without notes.
- No test coverage on payment or auth flows.
- Bus factor of 1 on any production system.
- Unresolved critical CVE older than 90 days.
- No deploy in the last 30 days.
- No incident log or post-mortems.
- 30%+ annual engineering attrition.
- Founder is the only person with production deploy access.
Any of these alone slows DD. Two together can kill a deal.
Pre-DD audit
If you have a fundraise coming and want a friendly DD before the real one, I do 4-week tech DD prep engagements. You leave with the gaps fixed and the docs ready.
Book a discovery call