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.
What is Technical Due Diligence?
Before a buyer or investor writes a check, they bring in a technical team to open the hood on the product. They're looking at code, infrastructure, security, team structure, and processes.
The demo might be flawless. The revenue might be growing. None of that matters if the foundation is hot garbage.
Deal Killers: These end the conversation
01. 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.
02. 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.
03. 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.
04. 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 will cost you money
05. 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.
06. Technical debt with no inventory. Every product has tech debt. But if you can't tell a buyer WHERE it is and HOW MUCH of it you have, they assume the worst.
07. No CI/CD pipeline. Manual deployments mean slow releases, human error, and no rollback plan. It signals that your engineering org is immature.
08. No environment separation. If your dev, staging, and production environments are the same environment, you're testing in production.
09. 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.
10. Security gaps. No penetration testing, no vulnerability scanning. 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.
11. 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: AI built it. Nobody checked it.
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.
12. 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 (human or AI), 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.
13. 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.
14. 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. Git never forgets, even if you delete the file later.
15. No database migrations or schema management. If your database changes are manual SQL scripts or someone logging in and running ALTER TABLE by hand, your data layer is a house of cards.
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.
Henry Irvin, Fractional CTO for EdTech & Healthcare SaaS. henryirvin.com