SaaS businesses can command the highest multiples in the SME market — but they also face the most forensic technical due diligence. Buyers will look inside the product, not just at the P&L. Prepare accordingly.
Quick Answer
To sell a SaaS business in the UK, prepare your MRR and ARR reports, churn and retention data, customer contracts and subscription terms, evidence of source code ownership, IP assignment records from contractors, cloud infrastructure costs, security and data protection records, and technical documentation. Buyers will value the business primarily on recurring revenue quality and will run a technical due diligence process alongside the financial review.
Contents
What makes selling a SaaS business different?
SaaS businesses — Software as a Service — sell access to software on a subscription basis. Customers pay monthly or annually; the business delivers ongoing software access, support and updates. This model creates recurring revenue that is more predictable and more valuable than most other income types, which is why SaaS businesses typically command higher acquisition multiples than comparable-profit businesses in other sectors.
But the same characteristics that make SaaS businesses attractive also make them more complex to sell. A buyer is not just acquiring revenue — they are acquiring the software product itself, the codebase, the infrastructure, the intellectual property, the customer contracts and the technical capability needed to maintain and develop the product. If any of these elements is unclear, unowned or unreliable, the valuation suffers.
A buyer may be acquiring:
Monthly or annual recurring revenue (MRR/ARR)
Customer base and subscription contracts
The software product — web app, mobile app, desktop software, API
Source code and codebase
Cloud infrastructure — AWS, GCP, Azure, hosting arrangements
Domain name and product brand
IP — trademarks, patents, design rights, copyright in the software
Technical documentation — architecture, API docs, deployment guides
Customer support systems and knowledge base
Sales and marketing assets — website, CRM, email lists
Staff — developers, customer success, sales
Contractor relationships
Data — customer data, usage data, analytics
Each of these requires specific preparation and verification. Technical due diligence — a process unique to software businesses — will assess the quality and risks of the codebase, infrastructure and security posture alongside the financial review.
How SaaS businesses are valued
SaaS businesses are most commonly valued on a multiple of Annual Recurring Revenue (ARR) or, for smaller businesses, a multiple of adjusted EBITDA or SDE (Seller Discretionary Earnings).
ARR multiplesare more commonly used for higher-growth SaaS businesses where profitability has been deliberately depressed in favour of growth investment. For profitable bootstrapped SaaS businesses — the type most commonly sold in the UK SME market — EBITDA or SDE multiples are often more relevant.
What drives the multiple up:
Low gross revenue churn — customers renewing, not leaving
Negative net revenue churn — existing customers expanding their spend (upgrades, add-ons, seat growth)
Strong net revenue retention (NRR) above 100%
Long average customer lifetime
Diverse customer base — no single customer exceeding 5–10% of ARR
Annual billing cycles that provide upfront cash
Strong gross margin — cloud costs are a fraction of revenue, not a substantial drag
A product with genuine switching costs — integrations, data lock-in, workflow dependency
Clean, documented, maintainable codebase
Technical team that will stay post-acquisition
Evidence of product-market fit and a clear product roadmap
Clean IP ownership — no ambiguity over who owns the code
What drives the multiple down:
High gross churn — customers cancelling frequently
Revenue concentrated in a few large customers
Founder-led sales where all new revenue depends on the owner
Codebase that is undocumented, outdated or technically fragile
Infrastructure that is under-specified, insecure or expensive to scale
Open-source components used in ways that may create licence obligations
Contractor-written code without IP assignment agreements
Customer contracts with weak or absent change-of-control clauses
Data protection gaps — particularly where the product processes personal data
Security incidents or vulnerabilities
MRR, ARR, churn and retention: the key metrics
These are the metrics buyers will scrutinise most carefully. Sellers should understand and be able to present each one before going to market.
MRR (Monthly Recurring Revenue).The normalised monthly revenue from subscriptions. MRR excludes one-off payments, professional services and setup fees. If a customer pays annually, their ARR divided by 12 is their monthly contribution to MRR.
ARR (Annual Recurring Revenue).MRR multiplied by 12, or the sum of all annual subscription values. ARR is the primary valuation metric for most SaaS buyers.
Gross Revenue Churn.The percentage of ARR lost from customer cancellations in a given period, before accounting for expansion revenue from existing customers. High gross churn — above 10% annually for SMB-focused SaaS — is a significant concern.
Net Revenue Retention (NRR).Also called net revenue churn. NRR measures what happens to a cohort of customers' revenue over time, accounting for cancellations, downgrades, upgrades and expansions. An NRR above 100% means existing customers are growing their spend faster than they are churning — this is a very attractive metric for buyers.
Customer Lifetime Value (LTV).Average revenue per customer divided by the gross churn rate. Tells buyers how long customers stay and how much revenue they generate over their lifetime.
Customer Acquisition Cost (CAC).Total sales and marketing spend divided by new customers acquired. Buyers will assess LTV:CAC ratio — typically a ratio above 3:1 is considered healthy.
Average Revenue Per Account (ARPA).ARR divided by customer count. Higher ARPA generally indicates more enterprise-facing products with stronger switching costs.
Cohort analysis.How does revenue from each cohort of customers (grouped by when they signed up) change over time? Healthy cohorts flatten or grow. Declining cohorts indicate a product or service quality issue.
Sellers should prepare a monthly breakdown of MRR for at least the past twenty-four months, showing new MRR, expansion MRR, contraction MRR and churned MRR. This waterfall view of MRR is standard in SaaS due diligence.
Financial information to prepare
Accounts.Three years of filed accounts showing total revenue, gross margin, overheads and net profit.
Management accounts.Year-to-date figures for the current year.
MRR/ARR report.A monthly breakdown of recurring revenue for at least twenty-four months — new, expansion, contraction, churned and net MRR.
Revenue by customer.A complete customer list with ARR contribution, start date, plan tier and renewal date. Buyers use this to check concentration, identify at-risk customers and understand the contract profile.
Revenue by product/tier.If the product has multiple pricing tiers or add-on modules, show the revenue split.
Gross margin calculation.Revenue minus cloud infrastructure and hosting costs, payment processing fees and any direct support costs. SaaS gross margins are typically 70–90% — materially lower margins indicate infrastructure inefficiency or significant support overhead.
Cloud and infrastructure costs.Monthly cloud spend — AWS, GCP, Azure — broken down by service where possible. Buyers want to understand the unit economics of serving each customer.
Customer support costs.If there is a significant support overhead — multiple support staff, high ticket volume per customer — this affects the gross margin and valuation.
Payroll.Developer salaries, customer success costs, sales costs and any other staff expenses.
Add-back schedule.Owner salary above market rate, personal costs, one-off expenses.
Deferred revenue.If annual subscriptions are billed upfront, there will be a deferred revenue balance on the balance sheet. Buyers and sellers must agree how this is treated in the sale — it is a liability from an accounting perspective, but a cash flow benefit in practice.
VAT.For SaaS businesses supplying B2B customers in the UK, standard VAT rules apply. For B2C digital services sold to EU customers, the OSS scheme may apply. Ensure VAT compliance is up to date.
Customer contracts and subscription terms
Customer contracts — or the terms of service that govern subscriptions — are critical documents in a SaaS sale.
Change-of-control clauses.Some enterprise customer agreements include change-of-control provisions that allow the customer to terminate or renegotiate on a change of ownership. Sellers should review all customer contracts for such clauses and assess the risk. For a buyer, discovering that large customers have termination rights triggered by the acquisition can significantly reduce the value of the deal.
Auto-renewal terms.What are the notice periods required to cancel subscriptions? Longer notice periods reduce short-term churn risk.
Price lock-in.Do contracts lock in pricing for a defined period? Buyers will want to understand when they have the ability to reprice customers.
SLA obligations.What uptime, support response and resolution commitments have been made? Are there penalty provisions for SLA breaches? Are there any outstanding SLA breaches or customer credits?
Data processing agreements.If the product processes personal data on behalf of customers, the business is acting as a data processor. This requires a Data Processing Agreement (DPA) with each customer. Buyers will check that DPAs are in place — the absence of DPAs is a regulatory gap under UK GDPR.
Enterprise agreements.Bespoke enterprise agreements may have specific terms — pricing, integrations, support levels, audit rights — that a buyer needs to understand and honour.
Self-service terms of service.For self-serve SaaS products, customers typically accept online terms of service. Sellers should confirm that these terms are current, reviewed by a solicitor and include appropriate limitation of liability, acceptable use policy, data protection provisions and governing law.
Source code, IP and contractor assignments
Intellectual property ownership is one of the most important due diligence areas in a SaaS business sale — and one of the most frequently overlooked by sellers until due diligence begins.
Who owns the source code?
Under UK copyright law, code written by an employee in the course of their employment is owned by the employer. Code written by a freelancer or contractor is, by default, owned by the contractor — not the business that commissioned it — unless there is a written assignment of copyright.
Many SaaS businesses have been built, in whole or in part, by freelance developers or agencies. If those developers did not sign an IP assignment agreement, the business may not own the code it depends on. This is a serious issue that buyers will identify in technical due diligence.
Before going to market, sellers should:
Identify every freelancer, contractor or agency that has contributed to the codebase
Check whether written IP assignment agreements are in place with each one
Obtain retrospective IP assignments where they are missing — before due diligence begins
Review employee contracts to confirm that code written by employees is owned by the business
Open-source components.Most SaaS products incorporate open-source libraries and frameworks. Some open-source licences — particularly GPL and LGPL licences — impose obligations on how the software that incorporates them can be distributed or commercialised. Buyers will assess whether any open-source components create obligations or restrictions that affect the business.
Trademarks.Is the product name or brand registered as a UK trademark? If not, a buyer faces the risk of a competitor registering the name. Sellers should consider registering key trademarks before going to market.
Patents.Less common in UK SME SaaS, but if any patents or patent applications exist, they should be documented.
Domain name.Is the domain registered to the business or to the founder personally? A domain registered personally must be transferred as part of the sale.
Cloud costs, infrastructure and technical documentation
Buyers will conduct technical due diligence on the product's infrastructure, architecture and codebase. This process is distinct from financial due diligence and is often conducted by a technical specialist — either employed by the buyer or brought in as an external reviewer.
Cloud infrastructure.Prepare a summary of the cloud setup — primary cloud provider, key services used, monthly costs and how costs scale with customer growth. Buyers want to understand the unit economics and the risk of infrastructure cost increases as the business grows.
Architecture overview.A high-level architecture diagram showing how the product is built — front-end, back-end, database, integrations, third-party APIs. This helps buyers and their technical advisers assess complexity and risk quickly.
Technology stack.Programming languages, frameworks, databases, caching layers, message queues. Is the stack modern and well-supported? Is it using technologies with active development communities, or older technologies that may become difficult to maintain?
Technical debt.Every codebase has some technical debt — shortcuts taken under time pressure, legacy code that needs refactoring, test coverage gaps. Sellers should be honest about the level of technical debt and what it would cost to address it. Hiding it is not a viable strategy — technical due diligence will find it.
Test coverage.Automated test coverage — unit tests, integration tests, end-to-end tests — gives buyers confidence that the codebase can be maintained and improved without constant regression risk.
Deployment process.How are code changes deployed? Is there a CI/CD pipeline? Is deployment documented and repeatable?
Uptime and reliability.Historical uptime records, monitoring setup, incident history. Buyers want evidence of a reliable product with a documented approach to incidents.
Third-party API dependencies.Does the product depend on third-party APIs — payment processors, mapping services, communication tools, data providers? Are these dependencies documented, contracted and what is the fallback if a third-party service is disrupted or discontinued?
Technical documentation.API documentation, developer guides, deployment runbooks, database schema documentation. Well-documented systems are easier to acquire and maintain — and command higher prices.
Security and data protection
Security and data protection are increasingly important in SaaS due diligence. Buyers — particularly those who are themselves subject to enterprise customer security requirements — will assess security posture as part of the acquisition process.
Data protection.SaaS products almost always process personal data on behalf of customers, making the business a data processor under UK GDPR. Key checks include:
Data Processing Agreements (DPAs) with all customers
Record of processing activities (ROPA)
Privacy policy and data subject notices
Data retention and deletion processes
Sub-processor agreements — third-party services that process personal data (cloud providers, analytics tools, email platforms)
Subject access request history
Data breach history and ICO notifications, if any
Security measures.Buyers will assess:
Access controls — who has access to production systems, customer data and cloud infrastructure
Authentication — multi-factor authentication for staff and, where appropriate, for customers
Encryption — data encrypted at rest and in transit
Penetration testing history — when was the last pen test conducted and what did it find?
Vulnerability management — how are security vulnerabilities identified and remediated?
Incident response plan
ISO 27001 or SOC 2.Certification to ISO 27001 or a SOC 2 report is not essential for UK SME SaaS businesses, but their presence significantly reduces buyer concern and can accelerate due diligence. If neither exists, sellers should be prepared to answer detailed security questions from buyers.
Staff, key people and handover
Technical staff
The development team — whether employees, contractors or a mix — is often the most critical asset after the product itself. Buyers will assess:
Who built the product, who maintains it and who is developing new features
Whether key developers are employed or contract
What retention risk exists — are key developers likely to leave after the sale?
Whether there is a bus factor — is one person the only one who understands critical parts of the system?
Employment contracts, notice periods and any existing restrictive covenants
Buyers may make the retention of key technical staff a condition of the deal. Sellers should think about retention packages for critical team members before going to market.
Founder dependency
Many SaaS businesses are founder-led in terms of both product direction and customer relationships. Buyers will assess:
Whether the founder is the only person who can make product decisions
Whether key customer relationships are personal to the founder
Whether the sales function operates without the founder's involvement
What the transition plan looks like — and whether the founder is willing to commit to a meaningful handover period
A SaaS business where the founder is the only technical person, the only salesperson and the primary customer contact is significantly harder to sell — and will command a lower multiple — than one where the team carries the business.
Handover
A typical SaaS handover involves:
Transferring access to all systems — cloud infrastructure, code repository, monitoring, support tools, analytics, CRM
Introducing the buyer to key customers and enterprise account contacts
Technical knowledge transfer — walking the buyer through the architecture, codebase, deployment process and known issues
Transition of customer support responsibilities
Agreed handover period — typically three to six months for smaller SaaS businesses
What mistakes should sellers avoid?
Presenting ARR figures that include non-recurring revenue.Professional services, setup fees and one-off charges are not ARR. Including them inflates the headline figure and creates credibility problems in due diligence.
Ignoring contractor IP assignments.The most common SaaS-specific deal issue. If freelancers or contractors built parts of the product without signing IP assignments, address this before going to market — not during due diligence.
Underestimating cloud costs.Sellers who present gross margin without correctly accounting for cloud infrastructure costs will have their figures adjusted by buyers during due diligence. Be accurate from the start.
Not having Data Processing Agreements with customers.This is a legal requirement under UK GDPR where the product processes personal data. Missing DPAs are a red flag in regulated-sector buyers.
Ignoring technical debt.Trying to hide technical debt never works — technical due diligence will find it. An honest assessment of known technical debt, with a realistic estimate of the cost to address it, is more credible than silence on the subject.
Presenting customer lifetime incorrectly.Lifetime value calculations based on optimistic assumptions about future churn rates are easily challenged. Use actual historical data.
Not documenting processes.A SaaS business where all operational and technical knowledge lives in the founder's head is harder to buy, slower to transition and commands a lower multiple.
SaaS seller checklist
MRR/ARR report prepared — monthly for at least 24 months, showing new, expansion, contraction and churned MRR
Gross revenue churn calculated — annually and ideally monthly
Net revenue retention (NRR) calculated
Customer list with ARR contribution, start date, plan and renewal date prepared
Customer concentration assessed — any single customer over 10% of ARR flagged
Cohort analysis prepared if available
Three years of filed accounts ready
Year-to-date management accounts prepared
Gross margin correctly calculated — cloud costs included
Cloud infrastructure costs documented monthly
Deferred revenue position on balance sheet understood and treatment agreed
Customer contracts reviewed — change-of-control clauses identified
Data Processing Agreements confirmed for all customers processing personal data
Terms of service/subscription agreement reviewed and current
SLA obligations confirmed and any outstanding breaches identified
Source code ownership confirmed — IP assignment agreements from all contractors
Open-source licence review completed
Trademark status confirmed
Domain ownership confirmed as in business name
Architecture overview document prepared
Technology stack documented
Technical debt assessed and documented honestly
Test coverage assessed
Security measures reviewed — access controls, MFA, encryption, pen test history
Data protection records prepared — ROPA, privacy policy, sub-processor list, breach history
Staff and contractor list prepared — roles, employment/contractor status, notice periods
Key person risk assessed — retention plan for critical technical staff
Handover plan prepared
FAQs
How is a SaaS business valued?
SaaS businesses are typically valued on a multiple of ARR (Annual Recurring Revenue) or adjusted EBITDA. ARR multiples vary widely depending on growth rate, churn, NRR, gross margin, customer concentration, product quality and market position. Profitable bootstrapped SaaS businesses in the UK SME market commonly achieve EBITDA multiples of 4x–8x or ARR multiples of 1x–4x, depending on quality. High-growth SaaS businesses may achieve higher multiples.
What is MRR and ARR?
MRR (Monthly Recurring Revenue) is the normalised monthly revenue from subscriptions. ARR (Annual Recurring Revenue) is MRR multiplied by 12, or the sum of all annual subscription values. These are the primary metrics used to measure and value SaaS businesses. Non-recurring income — one-off fees, professional services — is not included in MRR or ARR.
What is churn and why does it matter?
Churn is the rate at which customers or revenue is lost. Gross revenue churn is the percentage of ARR lost from cancellations. Net revenue retention (NRR) measures the net change in existing customer revenue, accounting for expansions and contractions. Low churn and high NRR indicate a product that customers value and continue to use — which makes the business more valuable. High churn suggests a product-market fit problem or a competitive issue.
Who owns the code if it was written by a freelancer?
Under UK copyright law, code written by a freelancer or contractor is owned by the contractor by default, not the business that commissioned it, unless there is a written IP assignment. This is a critical issue in SaaS business sales — all freelancer-written code should have a signed IP assignment agreement. Sellers who discover missing assignments should obtain them before going to market.
What is technical due diligence?
Technical due diligence is an assessment of the software product, codebase, infrastructure, security and technical documentation conducted by a buyer (or their technical advisers) before completing the acquisition. It assesses code quality, technical debt, security posture, infrastructure scalability, IP ownership and key-person risk. It is a standard part of any SaaS acquisition and sellers should prepare for it.
Do I need Data Processing Agreements with customers?
Yes, where your product processes personal data on behalf of customers, you are acting as a data processor under UK GDPR. You must have a Data Processing Agreement (DPA) in place with each customer. Missing DPAs are a compliance gap and will be identified in due diligence. Sellers should review and update DPAs before going to market.
Does TUPE apply to SaaS staff?
TUPE will normally apply to employees in a SaaS business sale conducted as a going concern. Employees transfer on their existing terms and conditions. Take specialist employment legal advice.
Key takeaways
SaaS businesses are valued primarily on recurring revenue quality — MRR, ARR, churn and net revenue retention are the central metrics.
Gross margin must correctly account for cloud infrastructure costs — not just revenue minus general overheads.
IP ownership of the codebase is critical — contractor IP assignments must be in place before going to market.
Technical due diligence is a standard part of every SaaS acquisition — prepare the architecture overview, technology stack, technical debt assessment and security posture.
Data Processing Agreements with all customers are a legal requirement under UK GDPR.
Customer contracts should be reviewed for change-of-control clauses before going to market.
Key technical staff retention is often as important as the financial metrics.
Document processes and technical systems thoroughly — it increases value and accelerates transition.
Related resources
Important disclaimer
Buy a Business Ltd is a marketplace, not a broker. Information, guides, checklists and examples on this site are for general guidance only and do not constitute legal, tax, financial, investment, valuation, brokerage or regulated advice.
Buying or selling a business involves risk. You should seek independent professional advice before buying, selling, valuing or financing a business.
Sources and useful references
ICO: Data sharing due diligence in mergers and acquisitions — ico.org.uk
ICO: Guide to the UK GDPR — ico.org.uk
GOV.UK: Digital services VAT — gov.uk
GOV.UK: Copyright ownership — gov.uk
Companies House: Get information about a company — find-and-update.company-information.service.gov.uk
GOV.UK: Business transfers, takeovers and TUPE — gov.uk