What buyers check in SaaS technical due diligence

Technical due diligence is where a SaaS sale slows down, and sometimes where the price drops. It rarely finds anything dramatic. It finds a hundred small things nobody had time to tidy, and each one becomes a question, a delay or a discount. Most of them can be fixed calmly if you start early.

1. Do you actually own the code?

Buyers check that every contractor and agency who wrote code signed over the rights to it. A missing assignment from a freelancer who built the first version is a surprisingly common problem. Find those contracts now, and get the missing ones signed while people are still reachable.

2. Open-source licences

Most of your product is open-source libraries, which is fine. Some licences, such as AGPL, can require you to publish your own code if you use them in a certain way. Buyers run a licence scan. Run it first, replace anything risky, and keep the report.

3. Security

• A recent penetration test by someone independent, with the findings fixed and re-tested.
• No passwords or keys in the code or the repository history. Buyers check the history, not just the current files.
• Dependencies with known vulnerabilities updated.
• Clear answers on how customer data is separated, backed up and protected.

4. Architecture and documentation

A buyer wants to know their own team can run the product after the sale. A short architecture overview, a diagram, setup instructions that work on a new laptop and a runbook for common incidents go a long way. They do not need to be long. They need to be true.

5. Cloud costs and margins

Infrastructure cost per customer feeds straight into the gross margin, which feeds straight into the price. Unused servers, oversized databases and forgotten test environments make margins look worse than they are. A cost review a few months before the sale often pays for itself several times over. If your product uses AI agents, the buyer will also ask for the model cost per task.

6. Key-person risk

If one engineer is the only person who understands deployments, billing or the data model, the buyer sees a risk and prices it in. Spread that knowledge: documentation, a second person who has done each critical job at least once, and access that does not live in one person’s password manager.

7. Numbers that come from the product

Revenue, churn and usage figures pulled directly from the product database are more convincing than a spreadsheet updated by hand. If the two disagree, expect questions.

A realistic timeline

Two to three months before you expect a buyer’s engineers, run your own due diligence: ownership, licences, a security review, documentation and a cost check. Fix what you find. Then you hand over a tidy data room and spend the sale answering questions instead of scrambling.