A few months ago, I was involved in evaluating a software company for a potential acquisition.
At first glance, it looked like an excellent opportunity.
The business metrics were strong.
Revenue was growing steadily.
Customer churn was low.
The product had healthy market fit.
Their sales pipeline looked healthy.
Honestly, everyone in the room was excited.
This seemed like a deal we should move fast on.
Then we started a deeper technical due diligence review—the kind used to assess code quality, architecture risk, security exposure, and long-term maintainability before acquisitions.
That’s when everything changed.
We got access to the engineering environment, architecture documents, and parts of the codebase.
Within the first day, I noticed issues that weren’t reflected in the financial reports.
At first, the issues were small; then, as we dug deeper, bigger ones emerged.
A software company can look amazing on paper yet still be a terrible acquisition, because in software businesses, the most important asset often isn’t visible in the boardroom—it’s the code, and code can hide many problems. By the end of the review, I realized that technical due diligence can reveal what financial reports miss.
Here are the 15 technical red flags I now look for before acquiring any software company.
Red Flag #1: Massive Technical Debt
The first thing we noticed was that the engineering team had moved fast. Features shipped quickly, but shortcuts were everywhere: duplicated logic, quick patches, inconsistent patterns, and messy modules. Nothing was clean.
Technical debt isn’t always bad. In fact, structured technical debt analysis often reveals whether shortcuts were strategic or simply unmanaged risk.
Startups need speed.
But too much debt becomes dangerous.
It slows everything.
Red Flag #2: Poor Code Quality
We found enormous files, functions that did too much, inconsistent naming conventions, and situations where even simple changes required understanding of multiple unrelated components, making everything expensive. Ultimately, bad code drives up the bug rate, increases onboarding time, and raises maintenance costs.
Red Flag #3: Almost No Tests
I was surprised that a product serving thousands of customers had minimal test coverage; when I asked, “How do you safely release changes?” I was worried to learn the answer was mostly manual testing, meaning every deployment carried risk.
Red Flag #4: Legacy Architecture Hidden Behind Modern UI
The frontend looked modern—a beautiful product on the surface—but the backend spoke a different story: old services, obsolete infrastructure, and legacy dependencies. This happens a lot; a polished UI can easily hide a fragile architecture.
Red Flag #5: Security Gaps
We found several concerning issues:
None had caused a breach yet, but “yet” is the dangerous word.
Security issues reduce trust fast.
Red Flag #6: Dependency Risk
It’s normal for modern software to run on open source, but dependency sprawl is risky.
We found packages that:
That introduces technical and legal risk.
Red Flag #7: Poor Documentation
There wasn’t much architecture documentation.
Then I asked:
“If key engineers leave, can someone else operate this?”
Silence.
That silence told me enough.
Red Flag #8: Single Engineer Dependency
Every company has strong engineers, but in one case, a single engineer understood everything—database, infrastructure, and core services—which was alarming because what happens if that person leaves?
Red Flag #9: Scalability Bottlenecks
The product handled current traffic.
But I kept asking:
Can it handle 10x growth?
We identified bottlenecks in:
database queries
synchronous workflows
caching strategy
Growth often breaks weak systems.
Red Flag #10: Poor Monitoring
Something else stood out.
Observability was weak.
Minimal:
If something breaks, diagnosing it becomes painful.
That increases downtime.
Red Flag #11: Cloud Cost Inefficiency
Revenue growth looked great, but infrastructure spending was rising too fast.
We found:
oversized instances
inefficient workloads
wasteful compute usage
Software that scales costs faster than it generates revenue becomes problematic.
Red Flag #12: Weak DevOps
Releases were stressful, deployments were partially manual, and rollback was messy—all of which created significant operational risk.
Good software isn’t just built well.
It’s deployed well too.
Red Flag #13: AI-Generated Code Everywhere
Large parts of recent features were AI-assisted.
AI is making teams faster, but speed without governance is risky.
We found AI-generated code with:
This is becoming common. Modern acquisitions increasingly require AI-generated code risk assessment to evaluate whether AI-assisted development introduced security or compliance issues.
AI writes code fast; it doesn’t guarantee good code.
Red Flag #14: Compliance Blind Spots
For regulated industries, this matters a lot.
I checked for audit logs, access governance, compliance controls, and found they were missing.
That creates legal exposure.
Red Flag #15: No Engineering Governance
This was the biggest issue.
Nobody owned long-term code quality.
There was no clear process for:
architecture reviews
coding standards
debt management
That means risk compounds silently.
What Changed for Me
That acquisition changed how I think.
Earlier, I looked mostly at:
revenue
growth
margins
market opportunity
Now I ask something else.
How healthy is the software asset?
That question matters more than many investors realize.
Because bad code creates hidden liabilities.
And hidden liabilities reduce value.
My Take
Today, I believe this:
Technical debt is not just engineering debt. It is acquisition debt.
A company may appear expensive or cheap depending on the quality of its software.
The codebase influences:
future engineering cost
scalability
security risk
operational resilience
In other words:
It influences valuation.
A lot.
Final Thought
If you’re acquiring a software company, don’t stop at financial due diligence. Go deeper and inspect the code, architecture, engineering culture.
Because sometimes the biggest risk isn’t visible in the pitch deck.
It’s buried in the codebase.
And that can cost millions later.
If you work in M&A, private equity, or technical due diligence and enjoy discussions around code quality, software valuation, and engineering risk, you can follow updates from The Code Registry. We regularly share insights on technical debt, AI-generated code risk, and software acquisition analysis.
I’m curious:
If you were acquiring a software company, what red flags would you look for first?