15 Things That Kill SaaS Deals During Technical Due Diligence
The demo might be flawless. The revenue might be growing. None of that matters if the foundation is hot garbage.
Deal Killers
These don't reduce your valuation. They end the conversation.
Copyleft/GPL/AGPL licenses in your core code
Certain open-source licenses can legally force you to open-source YOUR product. A buyer's legal team will catch this and either walk or demand you remove and replace those libraries before closing. Depending on where they are in your codebase, that can be a quick fix or a nightmare.
No IP assignment agreements
If contractors or co-founders wrote code without signing over ownership, you can't prove you own your own product. Nobody buys a lawsuit.
No automated tests
Zero test coverage means nobody can change anything without risking breaking something else. Every future feature becomes a gamble. Buyers see this as an ongoing liability they'll have to pay to fix.
Single point of failure engineers
If one person leaves and your product is in trouble, that's a hostage situation waiting to happen. Buyers call it "key person risk" and it scares them more than bad code.
Valuation Killers
These won't end the deal. But they will cost you money. Sometimes millions.
Poor or missing documentation
If your architecture only exists in someone's head, the buyer has to budget for the time and risk of figuring it out after close. That cost comes out of your price.
Technical debt with no inventory
Every product has tech debt. That's fine. But if you can't tell a buyer WHERE it is and HOW MUCH of it you have, they assume the worst.
No CI/CD pipeline
Manual deployments mean slow releases, human error, and no rollback plan. It signals that your engineering org is immature and will need investment post-acquisition.
No environment separation
If your dev, staging, and production environments are the same environment (or staging and dev don't exist at all), you're testing in production. One bad deploy and your customers feel it immediately.
No SBOM (Software Bill of Materials)
You need to be able to hand over a complete list of every dependency in your product. Versions, licenses, known vulnerabilities. If you can't produce this, it raises questions about what else you don't know about your own system.
Security gaps
No penetration testing, no vulnerability scanning. You don't necessarily need SOC 2 on day one, but if nobody has ever tried to break into your system on purpose, a buyer is going to wonder what they'd find if they did.
Vendor lock-in or non-transferable contracts
If your product depends on a contract that can't be assigned to the buyer, that's a problem. If your architecture is so tightly coupled to one vendor that migration would be a six-figure project, that's a bigger problem.
The Vibe Coder Special
This category didn't exist two years ago. Now I see it in almost every early-stage repo I open. AI can write code fast. That's the feature. The bug is that nobody reviewed what it wrote.
AI-generated code with no validation process
AI writes plausible code that looks right and hides subtle bugs. That's fine if you have automated tests, code reviews, and users putting it through its paces. The problem is when none of that exists and you're just shipping raw AI output straight to production with nothing checking its work.
No error handling or logging
When something breaks in production (and it will), can you figure out what happened? If there's no logging and no error handling, you're flying blind. Buyers see this and immediately start calculating how much monitoring infrastructure they'll need to build.
Hardcoded credentials in the repo
I've been in three client repos in the last five months. All three had private keys in the git history. That means anyone with repo access can get into production systems, third-party services, or customer data. Git never forgets, even if you delete the file later.
No database migrations or schema management
If your database changes are manual SQL scripts or worse, someone logging in and running ALTER TABLE by hand, your data layer is a house of cards. One mistake and you're dealing with data loss or corruption with no way to roll back.
Every single one of these is fixable.
Some take an afternoon. Some take months. The worst thing you can do is wait until someone else finds them for you.
If more than 3 of these apply, it might be time to get a second set of eyes on it before anyone else does.
Get in touch