You can learn an enormous amount about a technology business from its codebase. Not by reading every line, but by knowing the signals experienced engineers pick up on fast. In technical due diligence, these red flags don’t automatically kill a deal. Each one just tells you to look harder and price the risk before you commit. And that’s worth doing properly, because inadequate due diligence is cited in roughly 31% of failed mergers and acquisitions (Fortune). The flags below are how you avoid being in that group.
They fall into four buckets. Here’s the map, and notice the last one, because it’s the one most people miss.
flowchart TD
A(["Architecture and code"]) --> E(["How worried should you be?"])
B(["Process and practice"]) --> E
C(["Security and compliance"]) --> E
D(["How the team responds to scrutiny"]) --> E
E --> F{"Honest with a plan, or defensive?"}
F -->|Honest| G(["Price the risk, proceed"])
F -->|Defensive| H(["The bigger red flag. Dig in"])
Architecture and code. This is where the bones show.
- No one can explain how it works. If the team can’t clearly describe their own architecture, it’s either a tangle or the knowledge is locked in a couple of heads. Both are risks.
- Everything is entangled. When every change risks breaking something unrelated, development is slow and fragile, and it gets worse as the team grows.
- Debt that’s acknowledged but never touched. Some debt is normal. A big, growing pile that’s perpetually “next quarter” means future work will be slow and expensive, right when you need it fast.
- No tests. A codebase without meaningful automated testing is risky to change. Every new feature can quietly break an old one, and velocity collapses as it scales.
Process and practice. How they ship tells you how they think.
- No version control discipline or real deployment process. Chaos here predicts chaos everywhere.
- No documentation of critical systems. It raises key-person risk and makes everything slower to change or hand over.
- Manual work dressed up as automation. “Automated” or “AI-powered” features that are really people behind the scenes don’t scale the way the business case assumes.
Security and compliance. The inherited liabilities.
- Secrets in the code, no access control, no security habit. It signals both an immediate hole and a culture that treats security as someone else’s job.
- Personal data handled with no regard for PDPL or sector rules. A liability you inherit, and it surfaces at the worst time.
The meta-signal: how the team responds to scrutiny.
This is the one. A strong team is honest about their debt and their risks. They know exactly where the bodies are buried and they have a plan. A team that gets defensive, vague, or dismissive about real concerns is often a bigger red flag than any single technical issue. In our experience, the answer to “tell me what you’d fix first if money were no object” tells you more than any code review.
Need to know what’s really in the codebase before you invest or acquire? SDCG runs independent codebase and engineering assessments, then translates them into plain business-level risk. What’s solid, what’s concerning, and what it’ll cost to fix. We’re independent, so we’re not pitching a rebuild we’d love to sell you. Book a free 30-minute review.
Sources