Tech Due Diligence: A Practical Approach for Investors

Most technical due diligence reports tell you what the code looks like. That's not the same as telling you whether the technology can support the business. The gap between those two things is where deals go wrong — not in the code review, but in the failure to connect technical findings to commercial implications.

Here's the five-step framework we use. It's structured to surface business risk first and architectural detail second — because that's the order of priority for an investment decision.

Step 1: Start with the commercial questions

Before opening a single file, understand what the business needs from its technology. What are the three commercial outcomes that depend on the tech working? What would failure look like? What are the growth assumptions in the model, and does the current architecture support them?

This step shapes everything that follows. If you know the company is betting on 10× user growth in 18 months, you assess scalability with that specific number in mind. If you know the business is in a regulated sector, you prioritise security posture and compliance architecture accordingly.

Step 2: Architecture review

Now you look at the system. The architecture review covers three things: scalability, security posture, and technical debt. Each of these gets assessed not in isolation but against the commercial context from Step 1.

• Scalability: Where are the bottlenecks? What's stateless and can scale horizontally? What's stateful and will require re-engineering? What's the estimated cost of the next order-of-magnitude growth?
• Security posture: Authentication and authorisation model, data encryption at rest and in transit, third-party dependency risk, any known vulnerabilities in the dependency tree. In regulated sectors, also assess compliance architecture.
• Technical debt: Distinguish between debt that's been deliberately incurred and managed versus debt that's accumulated without awareness. The former is normal. The latter is a risk multiplier — it slows future development, creates hiring friction, and tends to be more expensive to resolve than anyone estimates.

Step 3: Team capability

Technology is only as good as the team that can maintain and evolve it. The team assessment looks at two things: engineering depth and dependency risk.

Engineering depth means: does the team have genuine expertise in the core technical domains the product requires? A machine learning product with no ML engineers is a concentration risk. A payments product built by a team with no security expertise is a liability.

Dependency risk means: how much of the critical technical knowledge is concentrated in one or two individuals? This is the single most common finding in early-stage tech DD — a founding CTO who is the sole owner of critical systems knowledge. The business risk of that person leaving is rarely priced into the deal.

Step 4: Product-technology fit

This is the question most technical assessments skip entirely: does the technology actually deliver what the product promises to customers? It sounds obvious. It's surprisingly often false.

Common failure modes: the demo environment is maintained separately from the production system and doesn't reflect real performance; AI accuracy claims are based on internal benchmarks that don't map to customer use cases; uptime and reliability figures are calculated in ways that exclude scheduled maintenance and partial outages.

Product-technology fit assessment requires talking to customers, reviewing support tickets, and stress-testing claims against production data — not just the architecture documentation.

Step 5: Risk summary for the IC

The output of technical due diligence should be a risk summary that investment committee members can act on — not a technical report that requires a computer science degree to interpret.

The summary should answer three questions directly: What are the material technical risks to this investment? What is the estimated cost and timeline to remediate each? And which of these are deal-breakers versus deal conditions versus acceptable risks to carry?

Technical findings that can't be translated into those terms aren't useful for an investment decision. The job of good tech DD isn't just to find problems — it's to give the decision-maker a clear picture of what they're actually buying.