Scaling SaaS from £1m to £20m ARR Without Breaking the Product

01

£1m ARR proves demand, not scale

Reaching £1m in annual recurring revenue is a meaningful point for a SaaS business. The product has customers, money is renewing and the company has moved beyond a promising idea.

It can still be held together by a surprising amount of effort.

Imagine a B2B SaaS product for service companies. Early customers were onboarded by the founder. Pricing was agreed in a proposal. A developer imported the first records. Support knew every account by name. A spreadsheet reconciled subscription changes, and one large customer had a few special screens because winning the contract mattered.

None of those choices was foolish. They helped the business learn what customers valued and get revenue through the door.

The problem appears when revenue grows but the effort behind each customer does not fall.

At £1m ARR, a manual onboarding step may be an afternoon. At several million, it becomes a queue. One custom permission becomes twelve account-specific rules. A billing exception becomes a monthly finance ritual. The support team becomes the integration layer between the product, CRM and subscription system.

Growing towards £20m ARR is therefore not just a bigger sales target. It is a test of whether the whole service can repeat.

The useful question is not, "Can the infrastructure handle more traffic?" It is, "Can the product, people and operating systems handle more customers without cost and confusion growing at the same rate?"

02

ARR describes size, but not the shape of growth

Annual recurring revenue turns current subscription income into an annual figure. It is useful for planning, comparing periods and describing the scale of a recurring-revenue business.

ARR alone can hide an unhealthy operation.

A SaaS company can add £2m of new ARR while losing £1.5m from existing customers. The headline grows, but sales is replacing revenue that already existed. Another company might retain almost every customer while support cost, cloud usage and manual onboarding make each account less profitable.

That is why the number needs a small set of measures around it.

Gross revenue retention shows how much starting revenue remains after churn and downgrades, before expansion is counted. Net revenue retention adds expansion from existing customers. If a group of customers starts the year at £100,000 ARR, loses £6,000 through churn and £2,000 through downgrades, then adds £10,000 through expansion, it ends at £102,000. Its NRR is 102%.

The 102% is useful, but it should not conceal the £8,000 that disappeared. GRR and NRR answer different questions, so looking at both gives a clearer picture.

SaaS Capital's 2026 survey of more than 1,000 private B2B SaaS companies reported a median growth rate of 22% and a positive relationship between NRR and growth. That is useful context, not a target every company should copy. Customer type, funding, price, market and product maturity all change what sensible growth looks like.

• ARR, new ARR and expansion ARR;
• gross and net revenue retention;
• customer concentration and contract size;
• time from signed contract to first useful outcome;
• support demand and cost to serve by customer segment;
• product usage that relates to renewal or expansion;
• reliability, failed jobs and incidents affecting customers;
• cloud and third-party cost by tenant or product area.

For the imagined SaaS business, a useful operating view might include:

The point is not to collect every SaaS metric on the internet. It is to connect commercial growth to the behaviour creating it.

03

The early shortcuts eventually become cost centres

The first signs of strain often look small. An implementation needs another checklist. Finance needs a new spreadsheet column. Support keeps a private document explaining one customer's setup. Engineers avoid changing a fragile feature before renewal week.

Each workaround may be manageable on its own. Together, they reveal that the product is not repeating cleanly.

The answer is not to automate every workaround immediately. Some exist because the team has not yet agreed what the standard product should do.

Fix the decision before scaling the mechanism.

04

Build for the target customer, not every large request

Large contracts create real pressure. A prospect may offer £180,000 ARR if the product gains a special workflow, isolated deployment or report built only for their organisation.

Saying yes may be commercially sensible. It may also turn a SaaS product into a collection of managed customer installations.

The decision needs more than a blanket rule against custom work. Ask whether the request reveals a need shared by the target market, supports a deliberate premium tier or can become configuration inside the standard product. Then price the product, implementation and ongoing service honestly.

A feature that serves one customer has a life after the contract is signed. It needs security review, tests, documentation, deployment, monitoring, support and future compatibility. If the account leaves, the maintenance usually stays.

That does not mean the roadmap should ignore large customers. Their requests can reveal valuable gaps. The mistake is allowing the loudest account to become the roadmap without comparing its needs with end-user behaviour, renewal evidence and the market the company intends to serve.

Product focus becomes more important as ARR grows because every exception travels further. It affects more releases, more support conversations and more people who were not present when the original promise was made.

05

Onboarding, billing and support are part of the product

A SaaS product is more than the application a user signs into.

The service starts when a customer agrees to buy. It includes creating the tenant, checking commercial terms, configuring roles, importing data, connecting integrations, training users, issuing invoices, handling subscription changes and supporting the account when something goes wrong.

At £1m ARR, those steps can live across helpful people. Towards £20m, they need a shared operational design.

Return to the imagined service software. A new customer currently signs a contract, emails a spreadsheet, books an onboarding call and waits while several teams create records in different systems. Nobody can see the complete journey. A delay in data import looks like a product problem to the customer and a project-management problem internally.

A repeatable onboarding flow would define the minimum information required, validate it early, create the right records, show ownership, surface exceptions and measure time to the first useful result. Automation can move standard cases. People can spend their time on judgement and unusual situations instead of copying the same values.

Billing deserves the same attention. Pricing tiers, seats, usage, discounts, credits, renewals and contract changes need to match what the product measures and what finance invoices. If product, CRM and billing systems use different definitions of an active customer, ARR reporting will eventually become a monthly argument.

Support is part of this loop too. A rising ticket count may mean more customers, poor onboarding, a confusing feature, an unreliable integration or a customer segment the product does not fit. Categorising and connecting support data to product usage and retention turns complaints into something the business can act on.

06

Scale the operating model before adding architecture

SaaS scaling conversations can jump quickly to microservices, queues, Kubernetes and multiple regions. Those tools may be useful. They are not a growth strategy.

The first architectural requirement is tenant awareness. The system needs a dependable way to identify the tenant, apply access rules, measure usage and understand the effect of a release or incident on that tenant.

AWS's SaaS guidance makes an important distinction: different tenancy models can be valid, but onboarding, identity, metering, monitoring and operations should still behave as one repeatable SaaS experience. Even a customer with isolated infrastructure should not require a completely different product version and a manual deployment ritual.

That principle helps the imagined SaaS business decide what to improve first.

If one customer's heavy report slows everybody else down, the team needs tenant-level usage and performance data before splitting the whole application into services. If onboarding fails because account creation crosses five manual systems, an automated tenant setup may create more value than another infrastructure layer. If every release needs a different sequence for six important customers, deployment standardisation is more urgent than raw compute capacity.

A well-structured monolith with background jobs, sensible caching, good database indexes, automated deployments and clear monitoring can support considerable growth. Breaking it into services too early adds network failures, distributed data, more deployments and a larger support surface.

Architecture should follow measured pressure. Change the part that cannot meet the required load, isolation, reliability or pace of change. Keep the rest understandable.

07

Reliability and security become commercial features

When a small SaaS product is unavailable, a few early customers may contact people they know. At higher ARR, an incident can interrupt hundreds of workflows, trigger contractual questions and fill several teams with urgent work.

Reliability needs a business definition.

A service-level objective, often shortened to SLO, describes the reliability customers need from a part of the service. It might cover availability, response time or the success rate of a critical job. The remaining tolerance is the error budget. It gives product and engineering a shared way to decide when the service can accept change and when reliability work must take priority.

The number should follow customer behaviour. A public marketing page and a payment run may not need the same target. Setting 99.99% everywhere sounds impressive until the business sees the engineering and infrastructure cost required to support it.

Security also changes with the customer base. Tenant isolation, administrative access, audit logs, data location, backups, recovery, incident response and staff permissions become part of sales, procurement and renewal conversations.

The National Cyber Security Centre advises SaaS users to consider how one tenant is prevented from reading another tenant's data, how provider access is controlled and logged, and how resilience choices affect availability. A SaaS provider needs credible answers before a large customer's security questionnaire arrives, not while the deal is waiting.

Reliable systems, safe access and tested recovery do not sit outside growth. They protect the recurring revenue the company has already earned.

08

The team needs a repeatable way to decide

Software cannot scale cleanly when every important decision returns to the founder.

As the company grows, product, engineering, customer success, finance, security and sales see different parts of the same customer journey. The work becomes slower when each team optimises its own queue and nobody owns the result across those boundaries.

Clear ownership does not mean creating a committee for every feature. It means agreeing who can make which decision, what evidence they need and when another team must be involved.

• product owns which customer problem belongs in the standard roadmap;
• engineering owns the safe technical route and makes operational risk visible;
• customer success owns the adoption and renewal signals from real accounts;
• finance owns the definition and reconciliation of recurring revenue;
• security and compliance define controls early enough to shape the design;
• leadership resolves trade-offs between growth, margin, reliability and focus.

For example:

These boundaries allow teams to move without pretending their decisions are independent.

A monthly operating review can connect the commercial and technical picture. It should not become a tour of dashboards. Pick a few questions: Which customer segment is growing? Where is revenue leaking? Which manual work rises with every account? What is driving support? Which part of the product threatens reliability or margin? Which assumption should be tested before more money is committed?

The answers create a shorter, more useful roadmap than a list of requests from every department.

09

Plan the next constraint, not an imaginary £20m company

It is possible to overbuild for scale.

A £1m SaaS company does not need the systems, team structure and infrastructure of a £20m company on day one. Building all of it early can consume the money and attention needed to reach the next customer.

The better approach is to make the next constraint visible and remove it before it becomes a crisis.

Map one customer from sale to renewal. Record every manual hand-off, exception, duplicate field and invisible decision. Connect those points to cost, delay, risk and customer experience. Then ask which problem will become materially worse if the company doubles.

The answer may be tenant onboarding, usage metering, deployment, billing, support knowledge, a fragile integration or a founder approval. Choose the smallest change that makes that part repeatable and measurable.

Repeat the exercise as the business grows.

Moving from £1m to £20m ARR is not one heroic scaling project. It is a series of decisions that stop revenue growth from producing the same growth in manual effort, product exceptions and operational risk.

If your SaaS product is growing but onboarding, support, billing or releases are becoming harder to control, bring me the workflow and the systems behind it. I can help map the constraint, decide what should remain simple and shape the next useful improvement before growth turns it into an emergency.