Most acquisitions don't fail because someone missed a brilliant insight. They fail because someone skipped the unglamorous check. Market-wide, M&A failure rates run as high as 70–90%, and in 83% of failed deals the cited reasons are poor strategic focus, poor cultural integration, or poor delivery of synergies (CAI, citing Harvard Business Review and Forbes). A surprising share of "synergy delivery" failures trace back to the one asset buyers under-inspect: the code. You're buying a software company for its software, and yet the technology is the most frequently under-scoped part of due diligence.
This is a field guide to ten red flags in a target's codebase — what each one looks like, why it costs you money after close, and how to spot it without being an engineer. Use it as a screening framework: any single flag is a question, several together are a renegotiation, and a few specific ones are a reason to walk.
Why the codebase is the cost you can't see in the financials
A target's books show revenue, margins, and headcount. They do not show that the product runs on a framework that went end-of-life three years ago, that one contractor holds all the deployment knowledge in his head, or that the "AI-powered platform" is a thin wrapper over code nobody on the current team understands. Those are the things that turn a clean-looking acquisition into an 18-month remediation project — and the research is blunt that technology diligence is "often under-scoped or delayed," leading to "costly oversights" that surface only after close (CAI).
The flags below are how that hidden cost announces itself early, if you know to look. We've grouped them so you can scan, but the framework matters less than the habit: translate every technical finding into a dollar-and-time question — what will this cost to fix, and how long until it bites?
The ten red flags
1. No clear architecture map. If no one can produce a simple diagram of how the system fits together — services, data stores, key dependencies — that's a flag in itself. It usually means the knowledge lives in a few heads rather than in the system's design, and knowledge in heads walks out the door at close. The first thing a real audit produces is this map; its absence tells you the team has been flying without one.
2. End-of-life or wildly outdated dependencies. Frameworks, languages, and libraries past their support window are unpatched security holes and migration debt rolled together. A platform pinned to an EOL runtime isn't just old — it's a forced, expensive upgrade you're inheriting on a clock you don't control.
3. Secrets in the code or commit history. API keys, passwords, and tokens hardcoded into the repository (or buried in git history) signal both an immediate security exposure and a culture that doesn't manage credentials carefully. Where there's one hardcoded secret, there are usually more. This is concrete enough to scan for directly — we cover how in finding exposed secrets in a GitHub repo.
4. Bus-factor of one. If a single person can explain (or deploy, or fix) a critical system and no one else can, you're not buying a company — you're buying a hostage situation. Retention of that person becomes a deal term, and their post-close departure becomes an existential risk. The research names "key technical talent retention" as a measurable driver of acquisition success for exactly this reason.
5. No tests, or tests that don't run. A codebase with little or no automated testing is one where every change is a gamble and every fix risks breaking three other things. It doesn't just slow future development — it makes the cost of any change unpredictable, which is poison to the integration timeline you're underwriting.
6. Undisclosed shadow IT and unlicensed components. Internal tools nobody documented, or open-source components used outside their license terms, are landmines. "Shadow IT including undisclosed or non-compliant software licenses" is on the standard list of diligence gaps that undermine deal value (CAI), because a license violation discovered post-close can force a costly rewrite or a settlement.
7. Tangled data and no clear ownership. Data siloed across systems with no clean model — or worse, customer data commingled in ways that complicate privacy compliance — is both an integration cost and a regulatory exposure. "Overlooked data silos that complicate integration" is another named gap (CAI); it's the difference between plugging the target in and rebuilding its plumbing.
8. Restrictive or hidden third-party contracts. Buried in the stack are vendor dependencies — a critical API, a hosting provider, a data source — sometimes on contracts with restrictive termination or change-of-control clauses. "Unreviewed third-party contracts that contain restrictive service or termination clauses" can directly hit deal value (CAI). A change-of-control clause that lets a key vendor walk on acquisition can gut the thing you're buying.
9. AI-generated code nobody understands. Increasingly common and increasingly dangerous: large volumes of code shipped fast by AI tools that no current team member can fully explain. It runs, it demos, and it hides risk no one has reviewed. If the team can't walk you through how a core flow works, "the AI wrote it" is not an answer — it's a flag. We dig into this in is your AI-generated code production-ready.
10. Heavy technical debt dressed up as "we'll refactor later." Underestimated technical debt — legacy systems quietly requiring a re-platform — is one of the most expensive gaps because it's the easiest to wave away in a sales process (CAI). The question to press is always specific: what does this cost to fix, and what happens to the roadmap if we don't? The honest answer reprices the deal.
How serious is each flag? A founder's triage
Not every flag is fatal, and treating them as equal is its own mistake. Here's a rough severity read to help you weigh what you find.
| Red flag | Typical severity | What it usually means for the deal |
|---|---|---|
| No architecture map | Medium | Hidden complexity; demand one before proceeding |
| EOL dependencies | Medium–High | A budgeted, scheduled upgrade you inherit |
| Secrets in code | High | Active security exposure + cultural signal |
| Bus-factor of one | High | Retention becomes a deal term |
| No working tests | Medium–High | Every future change is slower and riskier |
| Shadow IT / license issues | High | Possible forced rewrite or settlement |
| Tangled data | Medium–High | Integration cost + privacy exposure |
| Restrictive vendor contracts | High | A vendor could walk at change-of-control |
| Unreviewed AI-generated code | Medium–High | Unknown risk; demands deeper review |
| Heavy technical debt | High | Repriced roadmap; quantify before signing |
The pattern across the "High" rows is that they either threaten the asset's continuity (bus-factor, vendor walk-away) or carry open-ended cost (license violations, security exposure). Those are the ones that justify renegotiation or walking; the "Medium" ones are usually price adjustments and post-close plans. What you never want is to discover any of them after the wire clears.
How to actually find these before you sign
You find them by looking, early, and translating what you find into business terms — the work the research calls "structured IT due diligence" that buyers skip at their peril. For a non-technical acquirer, the fastest first pass is an automated one: pasting the target's GitHub link into SystemAudit's free scan returns an architecture map, a hidden-risks list, a security scan, and a prioritized fix plan in under three minutes — exactly the inputs you need to ask sharper questions in diligence, without waiting weeks for a consultant.
Two honest caveats. First, you typically need repository access to scan, which means the target's cooperation — itself a useful signal, since reluctance to grant a read-only look at the code is its own red flag. Second, an automated scan is a surface-level, prioritized risk pass, not a guarantee it has found every problem; it's the efficient start of diligence, the thing that tells you where to point a deeper human review, not a replacement for one on a high-stakes deal. For the broader checklist a full review should cover, see our code audit checklist and what investors look for in a code audit. And if you've already closed and are staring at a codebase you don't understand, inherited codebase, now what is the place to start.
Frequently asked questions
How many of these red flags should kill a deal?
It's not a count — it's which ones. A pile of "Medium" flags is usually a price negotiation and a post-close remediation budget, not a walk. But a single "High" flag that threatens continuity — a critical vendor with a change-of-control clause, a bus-factor of one who won't stay, a license violation that forces a rewrite — can be enough on its own. Severity and fixability matter far more than quantity.
Can a non-technical buyer really assess a codebase?
Not line by line, but you don't need to. You need the findings translated into business terms — cost to fix, time to bite, threat to continuity — which is exactly what a good audit (automated or human) produces. Your job is to ask the dollar-and-time question of every flag and to notice when answers are vague. "We'll refactor it later" and "the AI wrote that part" are non-answers, and recognizing them doesn't require an engineering degree.
What's the difference between a red flag and a deal-breaker?
A red flag is a question that demands an answer; a deal-breaker is an answer you can't live with. Outdated dependencies are a flag — the deal-breaker is learning the upgrade costs more than the company's annual profit. A bus-factor of one is a flag — the deal-breaker is that person telling you they're leaving at close. Flags reprice deals; deal-breakers end them, and the only way to tell which you're holding is to quantify the fix.
Why is AI-generated code a growing concern in acquisitions?
Because it lets small teams ship large volumes of code fast, which means more functionality nobody on the team has fully reviewed — and more risk hiding in code that runs and demos cleanly. In an acquisition, "it works" isn't the bar; "we understand it and can maintain it" is. If the team can't explain how their core system works because a tool generated it, you're inheriting unaudited risk at scale, and that warrants a deeper look before you sign.
How early in the process should the technical review happen?
Earlier than most buyers do it. The research is explicit that technology diligence is "often under-scoped or delayed in the transaction timeline," which is precisely why oversights surface after close. Run at least a surface-level scan as soon as you have repository access, so the findings can shape your valuation and your questions rather than arriving as post-close surprises. Late diligence isn't diligence — it's documentation of a decision you've already made.
Does a clean automated scan mean the codebase is safe?
No — it means the obvious, high-impact problems didn't show up, which is valuable but not the whole picture. An automated scan is strong at the concrete, common failures (exposed secrets, EOL dependencies, structural risk) and weaker at deep logic flaws, subtle architectural mistakes, and anything requiring human context. Treat a clean scan as "no red flags in the easy-to-check layer, now look harder at the rest," not as a clean bill of health for a deal you're betting real money on.
This article is general guidance for evaluating a software asset before acquisition, not legal, financial, or investment advice. Every deal is different; use these flags to inform sharper diligence questions and professional review, not to replace them.