Preparing a SaaS business for sale
Start 12 to 24 months before you expect a transaction. Use the first months to find out what a buyer will find, the middle period to fix what matters and build a track record, and the final months to prepare the evidence. A SaaS buyer will look hard at whether the platform, its costs and the team can support the recurring revenue and growth they are paying for.
- 24 to 18 monthsFind out where you stand
- Independent assessment
- Agree what matters with the board
- Start the long-lead issues
- 18 to 12 monthsFix the structural issues
- Reduce key person dependency
- Bring bespoke code back to one product
- Fix debt that blocks the roadmap
- Close security gaps
- 12 to 6 monthsBuild the track record
- Measure releases, incidents, uptime and hosting cost
- Document how it really runs
- Re-assess each quarter
- 6 months to signingPrepare the evidence
- Data room technology section
- Rehearse the technical sessions
- Decide on vendor DD
- During due diligenceKeep it steady
- One owner for technical requests
- No major change while the buyer looks
- Disclose known issues with a plan
- One product or many
- Hosting costs
- Reliability
- Ability to ship
- Customer data
- Security posture
- Dependencies
I spent seven years as CTO of iamproperty, so I know what it is like to run a SaaS platform while the business around it is thinking about its future. These days, at Stable State, I help founders and boards get their technology ready before a buyer looks at it. The pattern is nearly always the same: the issues that hurt a deal were known about internally, and there was simply never a good moment to deal with them. This timeline is how I would use the time, with a few anonymised stories from that work.
What SaaS buyers focus on
Technical due diligence on a SaaS business covers the same ground as any other technology review. These points tend to get particular attention because they bear directly on recurring revenue and margin:
- One product or many. Whether customers genuinely share one platform, or whether bespoke code, forks and single-customer deployments have crept in.
- Hosting costs. What the platform costs to run, and whether that cost grows in step with revenue or faster than it.
- Reliability. Uptime and incident history, measured against the commitments in customer contracts.
- Ability to ship. How often the team releases, how safely, and whether the roadmap in the plan is realistic at that pace.
- Customer data. Where it lives, who can reach it and how it is protected.
- Security posture. What enterprise customers are told in security questionnaires, and whether the evidence backs it up.
- Dependencies. Third-party services, integrations and components the platform cannot easily do without.
From experience: A SaaS business I assessed had grown revenue by around 40% in two years. Its cloud bill had more than doubled over the same period, and nobody had noticed because it was paid on a company card and lumped in with general overheads. A buyer would have spotted the gap between those two lines in minutes and asked what happens to margin at the next stage of growth. A few months of right-sizing and some long-overdue clean-up brought the cost back in line, and the business could show the trend turning before anyone asked.
24 to 18 months out: find out where you stand
The first job is an honest, independent view of the technology against what a buyer will examine. Internal teams are rarely well placed to do this: they are too close to it, and too busy delivering.
- Commission an independent assessment across strategy, product, team, approach, platform and security. A ClearView assessment does this in two weeks.
- Agree with the board which findings matter to the deal and which do not.
- Identify the issues with the longest lead times. Architecture change, team structure and key person dependency all take quarters, not weeks.
From experience: One founder told me, quite sincerely, that the platform was in good shape and the assessment was a box-ticking exercise. Most of it was in good shape. But the assessment also found that customer backups had never been test-restored, and that the one attempt, made by an engineer who had since left, had failed. Two years out, that was a week of work and a good story about a team that checks its assumptions. Discovered during due diligence, it would have looked like something else entirely.
18 to 12 months out: fix the structural issues
This is the window in which most material issues can genuinely be fixed. Start the long-lead work first.
- Reduce dependence on individuals. See key person dependency in technical due diligence.
- Bring customer-specific code back towards a single product, or at least make it visible and manageable.
- Address technical debt that blocks the roadmap or creates security exposure. See technical debt and company valuation.
- Close security gaps and put evidence behind existing controls.
- Pursue certifications only where customers or likely buyers will expect them.
From experience: I worked with a business that had spent most of a year working towards ISO 27001 because a competitor had it. Meanwhile, administrator accounts on the production platform had no multi-factor authentication, and former staff still had access to the source code. None of their customers had ever asked for the certificate. Every enterprise security questionnaire they had answered asked about the access controls. We changed the order of the work, and the certificate followed later, on firmer ground.
12 to 6 months out: build the track record
Buyers trust trends more than claims. A year of steady releases, falling incident numbers and controlled hosting costs says more than any management presentation.
- Start measuring the things a buyer will ask about, if you are not already: release frequency, incidents, uptime and hosting cost.
- Document the architecture and the operational processes the team actually uses.
- Re-assess progress each quarter so the board can see risk coming down.
From experience: One engineering team I advised started tracking just three numbers: releases per week, incidents per month and hosting cost per customer. For the first quarter the figures were not flattering, and the CTO was tempted to wait until they looked better. They kept going instead. By the time a buyer arrived there were four quarters of data showing all three moving the right way, and that chart did more work in the management presentation than any slide about the architecture.
6 months to signing: prepare the evidence
- Assemble the technology section of the data room. The technical due diligence checklist sets out what belongs there.
- Prepare the technology leadership for the management presentation and the technical sessions that follow.
- Decide whether vendor technical due diligence would strengthen your position.
From experience: Before one sale, I sat with a CTO and ran a mock technical session: two hours of the questions a buyer's reviewer would ask, asked the way they would ask them. Two answers fell apart under a follow-up question, not because anything was wrong, but because the CTO had never had to explain those decisions to an outsider. We spent a morning on each. In the real sessions, the same questions came up almost word for word, and this time the answers were short, consistent and backed by evidence.
During due diligence
- Give one person ownership of technical requests, so answers are consistent and nothing is lost.
- Avoid starting major technical change while the buyer is looking.
- Be straightforward about known issues and show the plan for each. A disclosed issue with a plan is a very different conversation from a discovered one.
From experience: A business I was supporting decided to start a long-planned database migration in the middle of due diligence, on the basis that it would show momentum. The migration hit a problem, there was a weekend outage, and the buyer's team was reading the incident report on the Monday morning. The migration was the right thing to do. The timing turned a routine piece of engineering into a question about whether the team could be trusted with the platform.
Common mistakes
- Starting when the information memorandum is being written. By then there is only time to explain problems, not fix them.
- A large rewrite shortly before a sale. Half-finished platform migrations create more risk in a buyer's eyes, not less.
- Documentation without change. Well-written documents describing unresolved problems do not reassure anyone.
- One person answering every technical question. It demonstrates the very dependency a buyer is worried about.
From experience: The hardest conversation I have had with a founder was about a rewrite. They were a year into rebuilding the platform from scratch, roughly half the customers had moved across, and they planned to go to market in six months. To a buyer, that meant two platforms to run, two sets of bugs and a migration with no certain end date. Pausing new features to finish the migration first pushed the sale back by a few months, and it was the right call.
Looking back on my own time as a CTO, and on the businesses I have worked with since, the companies that sold well were rarely the ones with the most impressive technology. They were the ones that started early, were honest with themselves about what a buyer would find, and fixed it while they still had the time.
Found 18 months before the deal, most of these issues are fixable. Found during due diligence, they become deal issues. The Technology Exit Readiness guide explains why.
Selling a SaaS business in the next two years?
Start with ClearView: a two-week assessment of what a buyer will find, and a plan to fix it.