What Do VCs Look For in Technical Due Diligence?

What Technical Due Diligence Is Really About

Technical due diligence is not a code review.

It is an attempt to understand how the business behaves under pressure. Investors are asking a simple question. Will the technology and the team hold when things stop going according to plan.

I have run DD on both sides of the table. For investors and for companies being evaluated. The pattern is always the same.

Code is the easiest part to analyse. Tools can scan it. Infrastructure can be inspected. None of that explains what happens when something breaks.

What matters is how decisions are made. How teams ship. How they recover.

The Two Questions Behind Every DD

Most DD conversations reduce to two scenarios.

What happens if your best developer leaves.

And what happens if the business grows 3–5× in a short period.

If losing one person can freeze delivery, delay incidents, or block releases, that is a real risk.

If growth multiplies load, support tickets, and operational work faster than the system can absorb, that is also a risk. Even if today everything looks fine.

Investors are not testing optimism. They are testing resilience.

What Investors Actually Pay Attention To

The strongest signals are behavioural.

Priorities. How the team decides what to work on when everything feels urgent. Who decides. And whether those decisions align with the business.

Quality of rollout. Not speed alone. Feature flags. Rollbacks. Gradual releases. Hope is not a release strategy.

Recovery. Incidents happen. Investors look at detection, response, and learning.

Ownership. Where knowledge lives. Whether critical systems depend on one person or are shared across the team.

These things are harder to fake than clean code.

Why Code Analysis Is the Easy Part

Static analysis is table stakes.

You can run SonarCloud or similar tools in a day. You can check if infrastructure is defined as code. You can see test coverage and pipelines.

Deals rarely slow down because of static analysis results.

They slow down when teams chased speed without enough process to recover. When releases rely on heroics. When basic hygiene was postponed for too long.

Where Deals Actually Get Stuck

The most common issues are not exotic.

Open-source licences nobody has reviewed. Hundreds of dependencies with no ownership.

Security checks done once, if ever. No regular penetration testing. No cadence. No clear responsibility.

Compliance ignored until it becomes urgent. No ISO thinking. No preparation. No plan.

None of these are fatal. Discovering them late creates friction, delays, and valuation pressure.

Common Red Flags

The biggest red flag is denial.

Teams that cannot explain why things are the way they are, or dismiss risks as future problems, slow deals down fast.

Single-person dependency is another. If one engineer leaving would paralyse delivery, investors notice.

Over-engineering can also be a warning sign early. Complex platforms before product–market fit often signal poor prioritisation.

Claiming to have no technical debt can also raise questions. Experienced investors know trade-offs always exist.

How to Prepare Before DD Starts

Run your own DD first.

Look beyond the code. Ask what breaks first under stress. People. Process. Systems.

Document decisions and trade-offs. Not just what you built, but why.

Know your weak spots. Licences. Security. Deployment risk. Knowledge concentration. Have a plan, even if incomplete.

Be clear about ownership. Who owns which systems. How handover works. How recovery happens when people are unavailable.

Metrics help. Behaviour matters more.

The Real Point of Technical Due Diligence

Technical due diligence exists to surface risk before it becomes expensive.

Most valuation hits do not come from bad code. They come from fragile teams and unclear ownership.

The fastest deals happen when nothing is surprising. When teams understand their system, their limits, and their next steps.

That is what builds confidence.