The Technical Due Diligence Checklist Investors Actually Use

When a founder shows you a product that runs, that used to tell you something. Today it often tells you the founder can prompt. A working demo stopped being proof the moment your neighbour's kid could vibe-code one in a weekend.

That's the problem most technical due diligence checklists haven't caught up to just yet.

Search for one and you'll find IT due diligence checklists written for acquirers: data-room inventories, licence registers, infrastructure sign-offs. Useful if you're buying a company's back office. Less so if you're a fund deciding whether the thing you're about to back is real and defensible, and able to carry the plan you're underwriting.

The checklist below is built for that decision: six areas, each judged by whether the tech and team can carry your thesis.

The technical due diligence checklist: six areas and the questions behind them

1. Architecture and scalability

The growth thesis usually assumes the platform scales, not vaguely, but specifically, from this many customers to that many in a set window. The architecture assessment has to be tied to that number.

• Can this onboard a hundred more customers, or can it only add rows to a database?
• Does it survive ten people working on it at once?
• Is there load-test evidence, or only the engineering team's word that it scales?
• Where are the bottlenecks, and what would remediation actually cost?

2. Security and compliance

Security is the area most prone to paperwork that describes a posture the production environment doesn't implement.

• Does the security posture in practice match what the certifications promise?
• What does the certification actually cover: the production platform, or just corporate IT?
• How recent is the last penetration test, and is there evidence the findings were remediated?
• How exposed is the dependency tree to known CVEs?

3. Code and delivery

Technical debt isn't inherently bad. Every production codebase has some, and some of it reflects sensible trade-offs. The question is whether it's been quantified, acknowledged, and priced in.

• Is the debt quantified, or just described?
• How is test coverage distributed? (80% on utility functions and 12% on payments is worse than 60% spread evenly. Ask for the report, not the headline.)
• What has delivery velocity done over time, and does the team know why?
• What does the incident history show: frequency, time to detection and recovery, and evidence the team learns from failures? (Weighs more at growth stage, where there's a track record to read.)

4. Team and organisation

Technology is inseparable from the people who built it. In a scan we read not just what the code does, but which person committed which part of it.

• Is there a single point of failure, a bus factor of one?
• Does critical knowledge live in people, or in documentation and systems?
• Does the company cleanly own what it's built?
• What would it take to keep the key engineers through the next phase?

5. AI readiness

This is the area with the widest discrepancy between how a pitch looks and what's underneath.

• Could this be rebuilt in a week by telling a model to go and build it?
• Is the AI genuinely defensible, or a wrapper dressed as a moat?
• Where does the data come from, how is it connected, and how is it used?
• Has the growth model priced in what the AI costs once the free credits run out?

6. Product and strategy

The roadmap is a promise. This area checks whether the promise is keepable with the current architecture and team.

• Does what they're building connect to where the value is actually created?
• Take the top three roadmap commitments for the next year: what would each cost to build, and does that match the financial model?
• Do any of them need platform-level work the budget doesn't reflect?
• Is the roadmap running on momentum, or on evidence of what customers pay for?

The best investors run it at the front, not the end

Part of why it got left to the end is a misread of what it's for. Run it as a code-quality exam and it feels like a formality, and a weak one now, because if a piece of the architecture is wrong you can rebuild it, and AI does much of that heavy lifting, so legacy code isn't the death sentence it used to be.

The ground has moved fast. A year ago, a report saying 30% of a company's code was written by AI made investors nervous and ask where the IP was; today the same number makes them wonder why the team is so slow. Same metric, opposite meaning, in twelve months.

Which tells you the real question was never how much AI a company uses, but whether what they built is defensible.

That's what an early read chases: whether the team can reach the next milestone, not the tidiness of the code. Whether they have the knowledge to rebuild what needs rebuilding and the process to do it without everything falling over. And whether they can prioritise fast enough to get where they said they're going. You can't generate that.

Managing Partner Mathijs de Wit says that "technical due diligence earlier in the process changes things, it unlocks deal speed. We put down high-valued term sheets with more confidence and use tech DD not only as confirmation, but to pay up for the quality now that we know what's really under the hood."

That's the argument for moving it forward. When you look early and the tech holds up, you don't spend three weeks confirming what you already know. You use the head start to move faster than the funds sitting next to you. When it doesn't hold up, you've found out before you've sunk a month into a deal that was never going to close.

What a checklist can't catch

There are two things a list won't surface, but they’re something you should keep in mind.

The first is a tell you get in the first five minutes of the intro call. When founders open with "here's what you're going to find, and here's why we haven't fixed it yet," nine times out of ten the company turns out to be good. They know you'll find whatever there is to find, so they just tell you.

The flip side is just as telling: a team insisting the product is so advanced you'll never find anything is usually where the alarm bells start.

The second is judgement about what the findings mean together.

Newion reads every scan the same way: are there red flags, is that red really red in their world, and where are the crown jewels, which is how a technical report becomes a fast investment call rather than a document. No checklist does that part for you.

How Scaleflow runs this

FAQs about technical due diligence

What is technical due diligence?

A structured review of a company's technology, product, and engineering; the assessment an investor runs before committing. It covers architecture and scalability, security and compliance, code quality and delivery, the team, AI readiness, and how all of it maps to the commercial plan. Traditionally it took weeks of interviews and self-reported metrics; increasingly it's run early, against the live codebase, so the read can shape the deal.

What does technical due diligence look like for an early-stage startup?

At the early stage the product is incomplete and will keep changing, so your read weighs execution risk (can this team build and ship toward the plan you're funding?) more heavily than the current state of the code. Ownership questions (who wrote it, did they stay, was the IP ever assigned) carry more weight than they sound like they should, and AI defensibility is often the line that decides it.

How are venture capital investors using AI in due diligence?