Seven 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 not a secret. Seven areas, in roughly this order: architecture, code quality and delivery, the team, security and compliance, IP and licensing, data and AI exposure, and whether the roadmap is buildable by the people named in the deck. Seed reviews run two to four weeks, Series A four to six.

Nobody is grading elegance. They are working out what has to be paid for and how soon. 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. Who sets the deadline does.

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, on a field operations platform we build: a feature 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 conventions file for one platform carries a 500-word rule about 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. The wiring broke, and nothing was testing the wiring.

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.

Count them on a field operations platform we build and you get 1,011 backend test methods against roughly 42,900 lines of production code, about one per 42 lines. The ratio is not a target and we would not defend it as one. What matters is that the suite 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 reads. On a healthcare platform we build the architecture sits in a form a machine can parse, and an agent audit against it turned up forty-two files' worth of drift in a single pass. Every one of those files had been through code review at the time. The useful question for a reviewer is not whether the document is accurate today. It 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 standing rule on our own projects is that an agent asks a human before adding a dependency. It sits on a very short list of actions that require a person, and it is there because a package brings someone else's licence terms into a company about to sell equity on the strength of owning its IP.

Diligence is not looking for a clean bill of health. It wants evidence that somebody looked: an inventory that was generated rather than remembered, 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 provenance for the AI-written code

Using AI is not the differentiator it gets sold as. Most UK businesses now report using it in some form, so reviewers have moved on: how much of the codebase was generated, who read it, and what tests cover the generated parts.

The healthcare platform we build answers that with a git query: 58 of its 117 commits carry an agent co-author trailer, accounting for roughly 65% of the churn once lockfiles are excluded. Nobody set that up for diligence. The trailer went into the commit template in the first week and nobody took it out.

What fails a review is not that a model wrote code. It is a codebase where nobody can say which parts were generated, and where the same process wrote the code and the tests that bless it. A trail showing the tasks we still take back off the agents 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. The flag is not that it can go wrong. It 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.

Nobody asks about your indexes. They ask 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 rather than fact, 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. Eleven decision records sit in a field operations platform we build, each carrying its status, date, authors and the alternatives that were rejected, including one that survived a single day before something better replaced it. We leave the dead ones in place with their banners on. 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 rather than tasks, which is why a quarter is the right notice and a fortnight is not.

A weak business does not become fundable on the back of any of this, and it would be a strange thing to claim. 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 long does technical due diligence take?

Two to four weeks at seed, four to six at Series A. Elapsed time is not the real cost. The cost is that it lands on the same engineers building the thing being valued, in the quarter you can least afford it.

Do investors read your code?

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 how much was generated, who read it, and what tests cover the generated parts. A commit trail answering those turns AI-assisted delivery into an asset.