The technical due diligence checklist investors work from

Technical due diligence works through seven areas: architecture and scalability, code quality and delivery, team and key-person risk, security and compliance posture, IP and open-source licensing, data and AI exposure, and roadmap credibility. What comes out is a list of findings, and findings get priced.

Technical due diligence is an investor's assessment of whether the engineering can carry the plan the money is buying. That framing decides how the checks are read. A rough codebase attached to a modest plan passes, and a tidy codebase attached to a plan it structurally cannot support does not.

Everything below is the working list, written so you can run it on yourself. Tick what you can evidence today; the rest is your preparation backlog. Most people find theirs in the last two areas.

How long it takes, and who turns up

The technical due diligence checklist on ctoondemand.com, updated July 2026, puts most venture reviews at one to three weeks and a complex acquisition at two to six. It adds that a data room prepared in advance cuts the timeline roughly in half. The UK providers priced further down publish turnarounds from about ten working days for a full review to a month. All of those are elapsed times from access to report. Much of the calendar is the target finding documents.

The split by round is our reading of how depth follows cheque size, not a published standard. Who runs the review varies. The same checklist names two options, the investor's in-house technical team or an independent firm. Rocking Tech says an investor can also have a corporate finance adviser or a law firm commission it. At the lightest end, Seedcamp's FAQ says it may continue its due diligence through questions over WhatsApp or email.

The person who turns up matters more than the stage. Some assessors are ex-founders who want thirty minutes with the engineer who wrote the hard part. Some are audit-shaped and want artefacts. You cannot pick, so the only defence that covers both is having the artefacts and being able to talk about them without the notes.

And nothing in the process is neutral information gathering. Every question is a hypothesis about a risk, and your answer either closes it or opens a larger one.

The seven areas, and what each is testing

The list is stable across firms, and the ctoondemand.com checklist quoted above names the same seven areas. What varies is depth, and depth follows cheque size. The failure modes underneath each area are covered in the seven red flags that stop a funding round. That is the other way to read this page: this one is what they ask, that one is what they find.

Every check on this page is also in a spreadsheet and a PDF. Download the checklist as a CSV or as a PDF, free and with no form. The spreadsheet has columns for who owns each check and where its evidence lives.

Architecture and scalability

• The system's shape can be drawn on one page by someone who did not build it
• Every major choice has a written reason, including the ones you would make differently now
• You can name what breaks first at ten times current load, and roughly what it costs to fix
• Tenant or customer isolation is a rule enforced in code, not a convention people follow
• A new engineer can run the whole thing locally in under a day
• Nothing in production depends on a machine, an account or a service only one person can reach

The assessor is working out whether the architecture was chosen. The question that does the work is "why this and not the obvious alternative", and the answer separates a team that made a decision from a team that inherited one from a tutorial. Nobody expects the answer to be impressive. They expect it to exist.

Which is why decision records are worth more than diagrams. On a field operations platform in a regulated compliance industry, each record in the repository carries status, date, authors, the alternatives rejected and the reviewer's objection even where the decision went the other way. A record that was reversed and kept does more for a reviewer's confidence than the ones around it that happened to be right first time, as the AI documentation pack argues.

Code quality and delivery

• Tests exist that fail when you break the behaviour they name
• The time from merge to production is a number you know
• There is a rollback, and somebody has used it this quarter
• A new engineer's first change reached production in their first week, and you can name when that last happened
• Dependency versions are current enough that upgrading is a task rather than a project
• The build is green on the main branch right now, and if it is not, everybody knows why

Delivery evidence beats code inspection, which is why assessors ask for the commit history before they ask for a code tour. DORA's 2025 State of AI-assisted Software Development found AI adoption correlating with higher throughput and higher instability at the same time, with more change failures and more rework. That is exactly the pattern a delivery review is designed to catch. GitClear's maintainability analysis of 623 million code changes, published June 2026, found duplicated code blocks up 81% since 2023 and developers roughly five times more likely to copy and paste than to refactor. Assessors read those reports too.

Our own practice, for calibration: on a field operations platform we build, automated tests run in every build. What we would want an assessor to check is whether a test goes red when you break the rule it claims to protect. A suite that stays green through a deliberate break is worse than no suite at all, because it has spent a year teaching everyone to trust it.

Team and key-person risk

• More than one person can deploy, and the second one has done it recently
• Each major subsystem has a named owner and at least one other person who has changed it
• Engineering conventions are written down somewhere a new starter gets pointed at
• Contractors have signed IP assignments, and you can produce them
• Someone other than the CTO can answer an architecture question in a call
• Holiday happens without a freeze

Gartner's prediction that 60% of organisations will adopt smaller engineering teams by 2029, published 7 July 2026 and up from 15% in 2026, describes exactly the shape most funded startups already have. The risk in a small team is undocumented concentration. An assessor can price a team of four. What they cannot price is a system only one person understands, which is a dependency with a notice period.

The mitigation worth starting with is a short set of written engineering conventions. On one platform we build, they point a reader at everything else: the architecture, the decision records, and a dated log of lessons for each feature area. A new engineer, or an assessor, reads the same pages and needs far less of anyone's afternoon. The question that ends more diligence calls than bad code has a cheaper answer than most founders expect.

Security and compliance posture

• You can list who can reach production data, and every access leaves a record
• No credential lives in the repository, and rotating one is a documented task
• Someone owns dependency vulnerabilities, with a decision rule for what gets patched when
• A backup has been restored, on purpose, and the restore was timed
• Every subprocessor touching customer data has a data processing agreement on file
• Customer-facing security questions have a written answer that is not invented per deal

The test is whether security is operational or ceremonial. A policy document dated eighteen months ago and never referenced is worse than no document, because it invites the assessor to check whether reality matches it. What passes is small evidence of routine: an access log somebody reads, a restore that was timed last month.

The pattern we lean on is making the evidence a side effect of the work. On a field operations platform we build, the audit record falls out of the write path itself, generated from the change that was made. Nobody can forget to log something, because logging is not a separate act. Compliance evidence that depends on discipline degrades. Evidence that depends on the code path cannot.

IP and open-source licensing

• A licence inventory exists, generated from the lockfile
• Nothing copyleft reaches your shipped or hosted product without a decision behind it
• Every contributor, employee and contractor has a signed assignment
• The company account owns the repositories, not a person
• Vendored and pasted-in code has a recorded origin
• Every change has a named reviewer on record

This area moved the most in 2026, because the provenance question arrived and most companies had no way to answer it. The specifics, including what auditors now ask about generated code and what review evidence answers them, are in open-source licences, AI-written code and your IP story.

Vagueness is the expensive answer. An assessor who cannot see how the code was reviewed has to assume it was not, and an assessor who cannot find a contractor's assignment has to assume it does not exist. Both are recoverable findings if you get to them first and unrecoverable in week two of a process.

Data and AI exposure

• You have a map of what customer data leaves your systems, to which vendor, under which agreement
• The privacy policy permits what the product does, in the words it uses
• You can name the features that stop working if a model provider changes pricing or terms
• Swapping a model is a configuration change with a test behind it, not a rewrite
• Somebody has tried to break your user-facing AI features on purpose
• If output reaches the EU, the transparency duties that landed in August 2026 are met

Concentration is what gets probed here. One AI feature on one provider means a single supplier for something customers now treat as core, and the assessor wants to know whether you have priced that. Per-token prices for a fixed capability level have fallen at a median of roughly 50x per year, per Epoch AI's price trend analysis from March 2025. That argues for building so substitution is cheap.

On a client marketplace we build, the control that mattered sat on the server. It rebuilds the assistant's output from a fixed list of fields, so anything the model invents cannot reach the database, and unknown fields fail closed. Behind that sits an evaluation harness for comparing models, built as where AI coding agents fail describes. It is what turns "we can swap providers" into a claim you can demonstrate in the room. Most of what we build is multi-tenant SaaS for regulated operations, which is where the patterns in this list come from.

Where output reaches Europe, the transparency obligations that arrived on 2 August 2026 apply. The question of whether the EU AI Act reaches a UK company turns on where output is used rather than where the company is registered.

Roadmap credibility

• The next two quarters of roadmap have visible foundations in the current codebase
• You can show what you cut, and why, on the last three things you shipped
• Estimates from six months ago can be compared against what happened
• The hiring plan matches the engineering plan, in both directions
• Someone owns the roadmap who is not also the person selling it
• Technical debt has a written list, with the interest rate on each item

This is where diligence stops being about the past. The assessor is comparing a plan against a codebase and asking whether one can produce the other with the team named in the deck. A roadmap that needs a rewrite of the data model in month two, with no mention of that rewrite anywhere, is the finding that costs the most and gets spotted the fastest.

The artefact we would put in front of an assessor here is the deletions. Every specification on a healthcare platform we build carries a non-goals section. Each non-goal names a specific mechanism that was deliberately not built, the reason it was not needed at this scale, and the condition that would trigger building it later. A roadmap that shows what you decided against, with the trigger written down, reads as a team that plans. A roadmap of only additions reads as a wish list.

What investors ask

Twelve questions an assessor is likely to ask in the first calls, each with the shape of a good answer. Every one maps to a check above, and every answer rests on something you can show.

What happens if you fail

Start with what nobody can tell you. The circulating figures about deals collapsing in diligence, and about technical findings cutting valuations by a fixed percentage, have no traceable primary source. We went looking and could not find one, so we will not repeat the numbers. Anyone quoting them to you is quoting a blog quoting a blog.

Findings usually change a deal's terms, in three ordinary ways.

The price moves. A remediation estimate becomes a deduction, and the argument shifts from whether the problem exists to what it costs. This is the outcome that rewards preparation most directly, because your own estimate for fixing something is always lower than an assessor's, and the one on the table first anchors the discussion.

Conditions attach to the money. Tranches against milestones, a senior hire before close, a specific piece of remediation as a condition precedent. These are common and survivable, and they are also a real constraint on the next twelve months.

The deal goes away. Rarely because of the code by itself, though. What ends a process is a finding that contradicts something the founders have already said. An assessor who discovers that the system does not do what the deck claims has stopped evaluating software and started evaluating people. There is no engineering fix for that one.

What technical due diligence for a startup costs in the UK

These are the figures on each firm's own page, read on 28 October 2026, for the providers that publish a price. "From" means an entry price, and the firms sell different scopes, so read the table as a spread rather than a quote.

The providers say the price moves with the size and complexity of the codebase or target and, for one of them, with the number of products in scope and whether AI components need hands-on testing. Boardman, a technology advisory firm, gives wider ranges in a guide of 10 December 2025: £15,000 to £50,000 for a buyer's review and £8,000 to £20,000 for a seller's pre-sale audit.

Run it on yourself, two months early

The standard advice is a self-assessment two to three months before you start raising, and it is right for an unglamorous reason: the artefacts take longer to assemble than the fixes take to make. Generating a licence inventory is an afternoon. Finding the signed contract for an engineer who left in 2023 is a fortnight of email.

Work in the order the findings are priced. The licence sweep and the contract chase first, because they have external dependencies and no engineering solution. Then key-person mitigation, which mostly means writing down what one person knows. Then the security basics, then an accounting of what your tests cover. That order, with the reasoning and the ninety-day schedule, is set out in preparing for technical due diligence: a 90-day plan.

For a quick read of where you stand first, the technical due diligence self-check asks questions from the areas above and scores your answers. If you would rather have an outsider run the whole thing, a pre-raise technical review is from £6,500, and its written report puts a fix cost beside every finding.

Every item on this page is something you want to be true whether or not anyone is raising money. The process just gives you a deadline.

Common questions

How long does technical due diligence take?

According to the July 2026 checklist on ctoondemand.com, most venture deals need between one and three weeks, with complex acquisitions at two to six. The same source says preparing the data room in advance roughly halves the time. UK providers publish turnarounds of about ten working days to a month. Preparation shortens a review more than cooperation does.

Do investors read your code?

Some do, briefly, and mostly to check that the code matches the story. More time goes on commit history, test suites, dependency files and decision records, because those show how a team works. Expect a walk-through where you drive and they ask why.

What is the difference between seed and Series A diligence?

Depth and formality, in our reading. Seed is often a few calls and a repository tour, and Seedcamp's FAQ says its own due diligence may run over email or WhatsApp. A later round more often brings a specialist firm, a written report for the investment committee, and questions about delivery metrics, contracts, subprocessors and security.

What happens if you fail technical due diligence?

Usually a repricing or a set of conditions rather than a collapse: a remediation estimate deducted from the valuation, milestones tranched, a hire required before close. Deals that die typically die because a finding contradicted an earlier answer, which is a credibility problem.

Does AI-written code cause problems in due diligence?

Only when nobody can account for it. An assessor needs to see who reviewed each change and whether the tests would fail without it. Open-source licences, AI-written code and your IP story sets out the records that answer both. Without them, the only assumption left is the pessimistic one.

When should we start preparing?

Two to three months before you open a round. The engineering fixes are quick; assembling contracts, licence reports, decision records and restore evidence is not. Starting once a term sheet exists means doing the assembly under a clock, which is when things get missed and answers get invented.