Tech due diligence red flags that stop a funding round

Investors rarely walk away over ugly code. What stalls a round is a finding that suggests the team does not know what it owns, or cannot show what it has done. Seven of those come up again and again, and every one is cheaper to clear in the quarter before a raise than in the fortnight during one.

Technical due diligence is an investor's estimate of what it will cost to keep your software working after their money arrives. We get called in on systems other people built, and we build systems other people's engineers later read, so these seven come from both sides.

What the reviewer is costing out

The scope is public. Seven areas, in roughly this order: architecture, code quality and delivery, the team, security and compliance, IP and licensing, and data and AI exposure. The seventh is whether the roadmap is buildable by the people named in the deck. A typical venture review takes one to three weeks, says CTO on Demand's July 2026 checklist.

The reviewer is working out what has to be paid for and how soon, not how elegant the code is. Work you deferred on purpose is fine; every team has some. Work you deferred without noticing is the expensive kind, because it means the plan you just sold was priced wrong and nobody knows by how much.

Data and AI exposure is the newest area, and it asks what leaves your trust boundary and under which agreements. If that output is used inside the EU, the obligations follow the market rather than the registered office.

The seven flags, and what each one costs

The engineering work barely changes between the last two columns, but the cost moves with who sets the deadline.

Nobody can build it from a clean checkout

The bar is unsophisticated. Clone into an empty directory, follow the README, get a working system without asking a human a question.

We run that test before every handover because it caught us once: a feature of a field operations platform we build read its content from files on disk at runtime. Every file existed in the working tree, so it worked on every machine we owned. Containers are built from tracked files only, so anything uncommitted was simply absent and the feature shipped inert. Local testing could never have found it, because locally the file is always there.

Getting there takes effort. The whole stack of a coaching platform we build comes up on a laptop under Docker Compose, with video, payments, messaging, search and document rendering running against emulators and mocks. A diligence reviewer is just somebody new with a deadline.

The test suite is green and proves nothing

Our written conventions for one platform give a whole section to a single framework trap. Register two validator classes against the same request type and the framework silently binds neither, so validation is off on both endpoints. It hides beautifully: the unit tests still pass, because they construct the validator directly and the validator is fine. A suite like that tests every part and never the wiring between them.

Coverage percentage would not have caught that. It measures how much code ran, which is a different question from whether anything was being checked while it ran. The better question is what happens when you break something on purpose.

On a field operations platform in a regulated compliance industry, the backend test suite is large beside the production code it covers. We would not defend that ratio as a target. It goes red when behaviour changes, and we have sat and watched it do that.

The architecture document and the code disagree

Every codebase has an architecture document. Most of them describe a system that used to exist.

The version that survives contact is one that something checks. On a healthcare platform we build, the architecture lives in a structured document. An audit of the code against it found drift in dozens of small ways that nobody on the project could see any more. Drift of that kind is hard to spot in review, because each change looks fine on its own. The useful question for a reviewer is how far things had slid before anything noticed, and what closed the gap.

Diligence surfaces this in conversation rather than in a scan. Ask an engineer to walk a request through the system with the document open on the other screen. The divergences arrive in the first three minutes, and the interesting part is whether anyone in the room is surprised by them.

Dependencies nobody chose

Nobody decides to take on a copyleft licence. It arrives inside something else, on a Friday, in a one-line change that passed review because the change was one line.

The control worth looking for is a rule that a person approves every new dependency, with the approval recorded where a reviewer can find it. It costs almost nothing to run, and it matters because a package brings someone else's licence terms into a company about to sell equity on the strength of owning its IP.

Diligence wants evidence that somebody looked: a generated inventory, with the awkward entries named and a sentence each on why they are acceptable. It is the one item here with a binary answer.

No review evidence for the AI-written code

Using AI differentiates nobody. Many UK businesses now report using it in some form, so reviewers have moved on to how it is controlled. They look for a named reviewer on every merge, and tests that fail without the change.

Neither is something a team builds for diligence. Both fall out of how the work already runs, which is why they cannot be written up afterwards: the record exists from the day the change merged, or it does not.

AI tools need a rule of their own: which ones are approved, and what data may go into them. A short written AI use policy is where that lives.

What fails a review is a codebase where nobody can show who read each change, and where the same process wrote the code and the tests that bless it. A history showing a person reading every change beats any claim about being AI-first.

Derived data with no way to rebuild it

Most systems carry derived data: a search index, a cache, a reporting table. Any of it can go wrong. The flag is that nobody has a route back.

Bulk writes on a healthcare platform we build deliberately swallow individual indexing failures, so a slow search cluster cannot block a write to the source of truth. Defensible trade, with a consequence printed on the tin: the two stores can drift. So the same platform has an index alias and a rebuild service that recreates the index from the database, catches up anything that changed mid-rebuild, then swaps the alias. "Reindex required" is a standing warning on roughly a third of the dated entries in that architecture decision log: a schema change is also a deploy instruction.

A reviewer asks what happens when the data is wrong. Restoring a backup and losing the day is a different company from rebuilding from source in an hour.

Documents that claim more than the code does

The dangerous documents are the confident ones: a readiness summary, a completion report, a standards page written before the thing it describes exists. All get read in diligence. Almost none get re-checked after the day they were written.

One specification on a healthcare platform we build marks its aspirational standards content as roadmap, and carries an open question asking whether it should be published before it is true. That open question is the artefact worth having. It tells a reader the team knows the difference, which is most of what this section is testing.

The rest is holding documents to the standard you hold code. On a field operations platform in a regulated compliance industry, every decision record carries its status, date, authors and the alternatives that were rejected. A reversed record stays in place with its banner, a habit we describe in the AI documentation pack. A reviewer takes about ninety seconds to tell a document set with reversals in it from one assembled the week the data room opened.

What to do with a quarter's notice

Run the review on yourself, in the order of the table. Start with the clean checkout: it takes a day and changes the first hour of everything that follows. The rest are habits, which is why a quarter is the right notice and a fortnight is not. If you would rather have an outsider read it first, a pre-raise technical review costs from £6,500 and hands you a written report before the investor sees anything.

None of this makes a weak business fundable. What the work removes is the findings that make a good business look careless, which is a smaller promise and one we can stand behind. We build and inherit multi-tenant platforms for a living, and every specific in this post came out of that work.

Common questions

How much of the engineering team's time does diligence take?

It varies with the codebase. The UK providers priced in the technical due diligence checklist quote between ten working days and a month for the review. The questions land on the same engineers building the thing being valued, in the quarter you can least afford it.

Who reads the code in a funding-round review?

Someone does, though less of it than founders fear. Most of a review goes on reading around the code: commit history, the test suite, the dependency manifest, the documents, and your answers about them. What gets assessed is whether those agree.

What happens when diligence finds something?

It depends whether the finding contradicts something you already said. A known weakness with a plan attached is an engineering conversation, and every system has a few. The same weakness found after you described things differently is a trust conversation.

Does AI-written code fail technical due diligence?

Not on its own. What fails is generated code with no review evidence behind it. Reviewers ask who read each change and what tests cover it. Where every merge has a reviewer on record and the tests fail without the change, AI-written code is an asset.