The Short Answer
The findings that most often derail deals during technical due diligence are not "the code is bad." They are systemic: a single engineer who built everything and is about to leave, no test coverage on the revenue-critical path, infrastructure costs that scale at 10x the rate of revenue, and security vulnerabilities that are known and unaddressed.
Those are red flags — findings that change the deal structure or kill it entirely. Yellow flags are real problems too, but the cost of addressing them is bounded and the business can continue to operate while they are fixed.
Most technical due diligence reports blur this line. When everything is listed as a risk without distinction, buyers cannot act on the findings. The job of a tech DD engagement is to separate the two categories clearly.
What Is a Technical Due Diligence Red Flag vs. a Yellow Flag?
A red flag is a finding that represents a hidden liability not reflected in the valuation, or a structural dependency that materially changes what the acquirer is buying.
A yellow flag is a genuine problem — deferred maintenance, suboptimal architecture, missing documentation — but the cost of addressing it is bounded and the business can operate while it is fixed.
The practical test: if you discovered this after close, would you feel deceived? A red flag passes that test. A yellow flag does not.
The distinction matters for deal structure. Red flags warrant escrow, rep and warranty protections, or price reductions. Yellow flags inform the integration budget. Treating them the same makes both categories meaningless.
The Red Flags That Most Often Kill Deals
These are the findings that cause buyers to pause, restructure, or walk away.
The senior engineer who built everything just gave notice. This comes up in roughly one in four engagements at the sub-$20M ARR level. One engineer wrote the core platform, holds all the institutional knowledge about the non-obvious architecture decisions, and has already accepted an offer elsewhere. The risk is not that the codebase is complicated — it is that the complexity is undocumented and lives in one person's head. If that person exits in the 90-day transition window, you are not buying a software business. You are buying a puzzle with a missing piece.
No test coverage on the billing path. When the checkout flow, subscription renewal, or payment processing logic has zero automated test coverage, the business is one deploy away from a revenue event. In a SaaS business at the $3M–$10M ARR range, an undetected billing defect typically surfaces within 60 days of a new deployment and costs 2%–8% of MRR to diagnose and remediate. That is not a cost you want to absorb during integration.
All infrastructure runs in one engineer's personal AWS account. The company has never formally owned its own cloud environment — credentials are tied to a personal account, billing to a personal credit card, and IAM permissions were never designed with the assumption that the account owner would leave. Migrating off that account requires freezing deployments, re-provisioning environments, and updating every service integration. During a six-month post-close integration, that is a serious distraction.
Known, unaddressed security vulnerabilities in customer-facing infrastructure. The key word is "known." Every software system has vulnerabilities. The red flag is documented vulnerabilities — in Jira, in Slack, in a security audit — that the team deferred indefinitely. In regulated industries and jurisdictions with breach notification requirements, "we knew and did nothing" is a different legal position than "we discovered it at the same time you did."
Infrastructure costs that have not scaled sub-linearly with revenue. If cloud spend grew 200% while revenue grew 40% over 18 months, the unit economics are broken. It usually means the system was over-provisioned, has no cost instrumentation, or has accumulated idle resources. Each scenario means the EBITDA you are buying is not the EBITDA you will have after close.
Red Flags That Don't Kill Deals but Change the Price
These are findings that belong in the integration budget, not the walk-away conversation.
No staging environment. Deploys go straight to production. It will cause incidents during integration. Not existential — two-to-four weeks to remediate, bounded cost.
Outdated dependencies with no active security advisories. Sixty packages behind their current major version is maintenance debt. Active CVEs in the dependency tree move this toward red; otherwise it belongs in the integration backlog.
Missing or inconsistent API documentation. The integration team works slower. That is a cost, not a crisis — and nearly universal in sub-$10M ARR software companies.
Monolith architecture with no clear service boundaries. The most common finding in SMB software acquisitions — and the one most buyers have already priced in. It makes the system harder to scale, but it does not prevent the business from operating. Add it to the integration timeline.
No formal incident response process. The team runs on hero mode. It is a retention risk and a scalability ceiling. It is not a finding that changes the underlying value of what was built.
How Should Investors and Acquirers Respond to Red Flags?
The first step is not to negotiate — it is to understand. A red flag is a hypothesis, not a verdict. Ask whether the founding team knows about it and has a plan, or whether they are surprised by it. A team that is surprised tells you something about engineering maturity. A team that can explain why it has not been addressed gives you something to work with.
Once you understand the context, the responses are:
Escrow tied to remediation. Set aside a portion of the purchase price — typically 5%–15% depending on severity — that releases when specific milestones are completed post-close. The most common structure for bounded red flags where you believe the seller.
Price reduction. When the remediation cost is estimable and the execution risk is yours, reduce the price by that estimate plus a risk premium.
Rep and warranty coverage expansion. For security vulnerabilities and known legal exposure, ensure the reps and warranties section specifically covers the findings in the DD report. Off-the-shelf rep and warranty insurance will not cover disclosed risks.
Walk. When the finding is a single-engineer dependency, no documentation, no transition plan, and the engineer is already out the door — walk. There is no escrow structure that compensates you for buying a system you cannot operate.
Can Red Flags Be Remediated Before Closing?
Sometimes. It depends on whether the finding is a documentation problem or a structural problem.
Documentation problems — an undocumented architecture, a personal AWS account with no access controls, a billing path with no tests — are remediable in 30–90 days if the engineering team is motivated and the timeline allows. Sellers who want to protect their price often prefer pre-close remediation to escrow, and that is a legitimate position if you trust the execution.
Structural problems — a broken cost architecture, a security vulnerability requiring an authentication redesign — do not remediate in a due diligence window. You are buying a post-close project, and you should price it that way.
The remediation conversation is a signal. A seller who offers a credible plan, assigns a specific engineer, and sets a verification checkpoint understands their business. A seller who disputes the finding or offers a vague commitment is telling you something about the post-close relationship.
Technical due diligence is not about finding reasons not to close. It is about buying with eyes open — knowing what you are inheriting, what it will cost, and where the real risks sit. The buyers who skip it are the ones who end up surprised at month six.
Learn how 11 Mile Co conducts technical due diligence engagements — and what a findings report actually looks like before you commission one.