5 Technical Red Flags That Could Derail a Software Deal

When evaluating a software company for acquisition, some technical issues are manageable with proper planning. Others signal deeper problems that could turn your investment into a costly mistake. In fact, technology-related issues account for around 40% of value destruction in tech acquisitions. The key is to identify these red flags before you sign a letter of intent, so you can make an informed decision (or walk away) with eyes wide open. Here are five technical red flags to watch for during due diligence, along with steps to address them if you choose to proceed.

1. Lack of Version Control History

If the codebase has no meaningful version control history – or worse, if a Git repository was only initialized recently from a ZIP file dump – you're missing critical context about how the software evolved. Modern development teams nearly always use a version control system (like Git) to track code changes, providing an audit trail of who changed what and when. Without this history, it becomes nearly impossible to understand how the product reached its current state, including:

• Which developer wrote which parts of the code, and when
• How bugs were introduced and later fixed
• The rationale behind past architectural or design decisions

A missing commit history might also conceal whether the code was forked or copied from elsewhere. Lack of this transparency is a serious red flag: it suggests either poor engineering practices or an attempt to hide potential issues.

What to do: Request access to the full version control repository (e.g. the Git repository). Review the commit history for continuity and depth. If little or no history exists, be prepared to invest significant time post-acquisition in rediscovering the code's context. Plan for a thorough code audit and documentation effort after closing, and factor that into your integration timeline. At a minimum, assume unknown bugs and design quirks will surface due to the missing historical knowledge.

2. Single-Point-of-Failure Developer (Bus Factor of 1)

When all critical knowledge resides with one developer and there's scant documentation, you're not buying a fully self-sufficient business – you're buying a key-person dependency risk. In technical due diligence, this is often called the "bus factor," referring (morbidly) to the number of people who, if lost, would cripple the project. A bus factor of 1 means one person's departure could bring development to a halt. Warning signs include:

• No up-to-date README or system architecture docs
• Critical processes or code that only one engineer understands
• Comments like "Oh, only [Name] knows how that part works," indicating tribal knowledge and siloed information

One due diligence expert recounted a case where a startup's entire platform depended on a single senior engineer, with core systems and deployment all in that one person's head. When that engineer planned to leave, the investors wisely walked away – and indeed, a few months later his departure plunged the company into an eight-month crisis trying to rebuild knowledge and systems.

What to do: Assess the team's knowledge distribution. If you find a bus factor of 1, demand a plan for knowledge transfer. This could include having the key developer create documentation, conduct training sessions, or stay on as a consultant for a transition period. In deal terms, you might negotiate holdbacks or earn-outs tied to successful knowledge transfer, or require the seller to retain the key person for a period of time. Be realistic about the ramp-up: if you acquire the company, allocate time and budget for new developers to shadow that person and document critical processes. Don't close the deal and simply hope that what's in one person's head will somehow transfer by osmosis – make it an explicit part of your integration strategy.

3. Serious Security Vulnerabilities (Customer Data at Risk)

Unpatched software vulnerabilities, outdated libraries, SQL injections waiting to happen, or credentials stored in plain text aren't just "technical debt" – they are serious liabilities. A major security breach or data loss event after you acquire the company becomes your problem (both legally and reputationally). It's not uncommon for an otherwise promising acquisition to turn into a nightmare overnight due to an unseen security hole. For example, if customer data is exposed or compliance requirements (GDPR, HIPAA, etc.) are not met, you could face regulatory fines or lawsuits immediately post-close.

Specific red flags to watch for include:

• Dependencies (open source or third-party) with known security vulnerabilities that haven't been patched
• Obvious web application flaws like SQL injection or cross-site scripting (XSS) weaknesses
• Hardcoded secrets or API keys in the code, or publicly accessible servers with no authentication
• Lack of encryption for sensitive data (either at rest in databases or in transit over networks)
• No evidence of security policies or past security testing

Each of these issues can be catastrophic. If the product handles customer data, any known critical vulnerability should put the deal on pause. In regulated industries, certain compliance gaps can even render the software unusable until fixed.

What to do: Conduct a security audit or vulnerability scan as part of due diligence – ideally using reputable third-party specialists or tools. Identify any critical vulnerabilities before closing. If you discover high-severity issues, you essentially have two choices: insist they be fixed pre-acquisition, or adjust the deal (valuation or warranties) to account for the remediation you'll have to do. Often, it's wise to require the seller to patch critical flaws (or at least agree on a remediation roadmap and escrow funds for it) as a condition of closing. Also ensure the company follows basic security best practices (e.g. principle of least privilege, proper access controls, backups and incident response plans). If the security posture is very weak, think hard about the potential fallout – it might be safer to walk away than to inherit a ticking time bomb.

4. No Automated Testing or QA Process

If a software product has zero automated tests – no unit tests, integration tests, or end-to-end test suites – then every code change becomes a gamble. Without automated testing, you can't confidently modify or scale the software:

• You risk breaking one feature when fixing another, with no quick way to detect it
• Upgrading any library or platform component (even for security fixes) could introduce bugs that go undetected until users complain
• Onboarding new developers is slower and riskier, since there's no safety net to catch mistakes or regressions

In short, a lack of testing signals fragility. The engineering team is essentially "flying blind" on quality. This often correlates with rushed development and high defect rates in production. As one due diligence report put it, teams that don't prioritize test automation suffer from more undetected regressions and reliability issues, increasing long-term risks for the product and the business.

For an acquirer, inheriting a codebase with no tests means you should budget significant time post-acquisition to build a test suite and stabilize the software. Depending on the size of the application, getting decent test coverage could take months. In complex systems, this effort is often on the order of 3–6 months of engineering work (and that's 3–6 months delay in working on new features or improvements).

What to do: During diligence, ask for any existing test plans or QA reports. If none exist, assume you will need to implement a full testing regimen ASAP. Price in the cost of adding test coverage and QA. This might include hiring QA engineers or reallocating the current team's time to write tests, set up continuous integration (CI) pipelines, etc. Make it part of your post-merger integration plan to introduce automated testing from day one. Additionally, consider requiring the seller to run a regression testing cycle before close to at least catch any glaring issues. If the system is mission-critical and has no tests, you should approach the deal with extreme caution – this usually indicates deeper engineering culture issues (like lack of code reviews or quality control). It's not necessarily a deal-breaker on its own, but you must go in with a clear remediation plan.

5. Unclear or Risky Software Licensing

Software licensing issues – whether open-source license violations, expired proprietary licenses, or reliance on unsupported third-party components – can completely derail an acquisition. These problems can range from legal landmines to operational dead-ends. For instance, if the target company's product incorporates open-source code under a restrictive license (like GPL) without complying with its terms, you as the new owner could be forced to open-source your entire codebase or face legal action. Similarly, if some core module is using an API or library that's no longer supported (or a commercial component without a proper license), the software might stop working or incur unexpected costs.

Some red flags and scenarios include:

• Use of copyleft open-source components (e.g. GPL-licensed code) intertwined with proprietary code, without proper disclosure or licensing compliance
• Missing attribution or license documentation for open-source libraries in the product
• No "bill of materials" for third-party software, making it unclear what licenses apply
• Proprietary software or SDKs being used beyond their allowed terms (e.g. using a "free" tier library in a paid product, or an expired OEM license)
• Intellectual property questions about who actually owns the code (e.g. a founder who copied code from a previous employer or project)

These issues can haunt you after the deal. One acquirer found out post-acquisition that a startup's "innovative" code was partially copied from a competitor and that the startup had embedded GPL-licensed components without permission. This resulted in a cease-and-desist from the competitor and a requirement to open-source large portions of the product – the new owner ended up rewriting 60% of the codebase and paying hefty legal settlements. No investor wants to be in that position.

What to do: Perform a license audit as part of technical due diligence. This means reviewing the software's open-source usage and verifying all third-party components. Many buyers engage specialized firms or tools (for example, Black Duck) to scan the code for open-source libraries and license compliance. Have legal counsel review any potential IP ownership concerns – ensure all code was written by employees or contractors under work-for-hire agreements, or that any external code is properly licensed. If you discover unlicensed use of software or open-source violations, demand that the target remediate these issues before closing (e.g. replace a GPL component with a permissively licensed one, or obtain proper commercial licenses). In some cases, you might negotiate an indemnity or escrow to cover potential claims. The goal is to eliminate or mitigate legal risks prior to acquisition so you're not buying a lawsuit. If the licensing tangle is too complicated to fix reasonably soon, it may be wise to walk away and look for a cleaner opportunity.

The Bottom Line

Each of these red flags by itself doesn't have to be a deal-breaker. Experienced buyers sometimes do acquire companies with technical debt or other shortcomings – but they do so with eyes open and a plan in hand. The common thread is that these issues must be discovered before the deal, reflected in the valuation or terms, and addressed with a clear post-acquisition strategy. That's exactly what thorough technical due diligence provides: a realistic assessment of technical risks and the roadmap to handle them. Remember, the goal isn't to find a perfect company (spoiler, those rarely exist), but to avoid unpleasant surprises that could destroy your investment.

By spotting the above red flags early, you can either bail out of a bad deal or negotiate conditions to manage the risks. In the end, a balanced, informed approach will set you up to capture the upside of an acquisition without stumbling over hidden technical pitfalls.

Need help evaluating a software acquisition? Our team at Sightway specializes in technical assessments for investors and acquirers. Get in touch to discuss how we can help you vet the code, the team, and the tech stack – so you can proceed with confidence.