Technical due diligence red flags

Across this guide the message is that most technical problems are fixable, so you price them rather than fear them. Warning signs are the exception. They are the findings that suggest a risk you cannot fully price, because they point to something structural in the team or the culture rather than a known amount of work. The main guide presents diligence as pricing risk against a thesis. Warning signs are where that pricing stops working.

What makes a finding a warning sign instead of a repair?

A finding is a warning sign when it cannot be sized, or when it points to the people rather than the code. A missing test suite can be sized: a competent team builds one in a known number of weeks. A team that does not know it needs one cannot be sized, because the finding is about judgment and the repair is about people. The first goes on the repair list. The second goes into the terms.

Reveneau's diligence reports keep warning signs on a separate page from the priced findings, because a deal team reading a single ranked list will price a structural risk as if it were a large repair, and a structural risk priced as a repair is how a deal that should have been renegotiated gets signed at the original terms.

Why is one person who understands the whole system the most serious warning sign?

Because the company's most valuable asset can leave with two weeks' notice, and no amount of clean code protects you from that. If one engineer is the only person who understands the core system, the roadmap the thesis depends on could be stopped by one resignation. The measure is the bus factor, the minimum number of people who would have to disappear before the project stops, and it is low in most software: a study of 133 open source systems by Avelino, Valente and Hora, cited on Wikipedia's entry for the term, found 65 percent had a bus factor of two or fewer.

This is worse than a code problem because money cannot solve it on a deal timeline. Spreading that knowledge takes months and the cooperation of the person who holds it, and Brooks's law (1975) says that adding people to a late project makes it later, so the fix cannot be rushed either. If the deal depends on the roadmap and the roadmap depends on one person, that risk belongs in the terms. The assessing the engineering team page covers how to measure it from the commit history rather than by asking, and the single developer risk page covers the pre-seed version, where one developer is normal and the question is different.

What does it mean when the team hides problems?

It means the priced list you built is incomplete, and you do not know by how much. How a team behaves during diligence predicts how it behaves after close. A team that is open about its debt, its outages, and its weak areas is showing you it will tell you the truth when you own it. A team that presents a perfect account, gets defensive under questions, or will not let you verify claims is showing you the opposite. Real software has old problems and past repairs, so a company that claims to have none is either inexperienced or hiding something, and both are a problem.

The signs are specific. A test suite that "usually passes" but cannot be run in front of you. An incident history with a gap where a known outage should be. An architecture diagram that does not match the live explanation. An engineer interview that keeps being rescheduled. Google's SRE book describes a postmortem as a written record of an incident, its impact, the actions taken, the root causes and the follow-up actions; a company that has had incidents and has no such records has either never learned from them or does not want you to see what it learned. This warning sign affects every other finding, because trust in the team's honesty is what lets you rely on the rest of the review.

Why are missing basic security practices a culture finding?

Because a team that skips necessary security steps under pressure skips steps on quality, testing and everything else too. When nobody controls who can reach customer data, secrets are stored in the repository, and there is no plan for an incident, the problem is rarely limited to security. Verizon's 2026 Data Breach Investigations Report states that 31 percent of breaches now start with a software vulnerability, so a team with no patching process has a current liability as well as a cultural one. The assessing security and compliance page covers what basic security practices look like; their absence everywhere is the warning sign, and a single missing control is a repair.

What does it mean when the team cannot explain its own system?

It means either the people who understood the system have left, or the current team is unable to handle the system, and either way you are investing in a roadmap that depends on a team that does not fully understand what it is building on. When a team cannot explain its own architecture, cannot say what breaks first as it grows, or cannot explain a past decision in plain language, that is the warning. Clear thinking produces clear explanation, so a missing explanation says something about the thinking behind it.

This warning sign has a modern form. In a codebase where a model wrote most of the code, the team may never have understood the system, because nobody read it. Stack Overflow's 2025 survey of more than 49,000 developers found 66 percent frustrated by AI output that is "almost right", and almost-right code that nobody read is code nobody can explain. The diligence on an AI-written codebase page covers what to ask for instead: the specifications, the review policy, and the evaluation suite that does the checking a human reader would do.

Why do slower releases matter more than the current speed?

Because a roadmap funded on the assumption of fast releases, given to a team that is slowing down, is a mismatch the deal will pay for, and past growth can hide the trend. A team that releases more slowly every quarter, where features that took days now take weeks, is a team whose technical debt is now slowing it down. The company may still be growing because of what it released two years ago.

Ask for the trend rather than the current state. DORA's delivery metrics make it visible: change lead time rising, deployment frequency falling, and change fail rate rising over twelve months is the typical pattern. Google's October 2024 DORA report also associated a 25 percent increase in AI adoption with a 1.5 percent decrease in delivery throughput and a 7.2 percent decrease in delivery stability, so a team that adopted AI tools and got slower is following a documented pattern rather than an unusual one. The assessing technical debt page covers how to size what is behind the slowdown, and the assessing code quality page explains the metrics.

Which AI claims are warning signs?

An AI claim that cannot be demonstrated on request is a warning sign, and from 2024 onward it has been a regulatory matter as well. In March 2024 the SEC fined Delphia $225,000 and Global Predictions $175,000 for false and misleading statements about their use of AI, in what the SEC chair called "AI washing". In September 2024 the FTC announced five enforcement actions under Operation AI Comply, including against DoNotPay, which had marketed "the world's first robot lawyer" without evidence that its service matched a human lawyer.

Claim on the deck	The test	Warning sign if
"Our AI does X"	Run it on your own input, live, during the review	It only works on the demo data
"Proprietary model"	Ask what was trained, on what data, by whom	It is a third-party model behind a prompt, and nobody said so
"AI-native, fully automated"	Ask what happens when the model is wrong	The answer is a person doing the work by hand, and nobody mentioned it
"Most of our code is AI-written and tested"	Watch the evaluation suite run	There is no suite, or it cannot be run
Gross margin in the model	Rebuild it from the inference invoices	The invoices show a different number

The how to verify an AI claim with a test page covers the first row, rebuilding inference gross margin from invoices covers the last, and AI demo versus the final step to production explains why a demo that works is the start of the question rather than the answer.

How do you read warning signs together, and what are the options?

One warning sign is a reason to look harder. Several together usually share a root cause: a team that grew too fast without senior guidance and skipped necessary steps in every area. That is why the areas of a review are read together. A warning sign is a reason to stop pricing and ask whether the thesis is still true.

Situation	Option	What it looks like in the terms
Bus factor of one on the core, person is staying	Renegotiate	Retention terms, knowledge transfer as a condition, a second engineer on the core within ninety days
Bus factor of one, person is leaving	Reconsider	A lower price that funds a rebuild by a new team, or leave the deal
Team hid a known problem	Reconsider	Widen the review before pricing anything; warranties for what was found
No basic security practices anywhere	Renegotiate	A remediation plan priced into year one, with a team change
Team cannot explain the system	Reconsider	Price as a takeover of an unknown codebase, or leave the deal
Releases slowing each quarter	Renegotiate	A slower roadmap in the model, debt repair funded, senior hires priced
Undemonstrable AI claim	Reconsider	The claim comes out of the model; if the thesis was the claim, leave the deal

Sometimes the answer is a lower price. Sometimes it is different terms, such as a contract that keeps a key person at the company. And sometimes it is leaving the deal, which a good review lets you do before the money is paid. Wiltbank and Boeker's 2007 study of 1,137 angel exits found 65 percent of exits with below-median diligence returned less than the money invested, which is what skipping this step costs on average. The technical due diligence checklist lists the questions that reveal each of these warning signs, the warning signs by stage page in the AI startup guide covers which ones matter at which stage for an AI company, and technical warning signs at pre-seed and seed covers the earliest stage, where several of the warning signs above are normal and the list is different.