How to buy a micro-SaaS

MRR is a headline, not a business. Here's how to read churn, cohort retention and support load before you buy a micro-SaaS, and price it on what actually recurs.

A micro-SaaS lives or dies on the quality of its recurring revenue, and the headline MRR number tells you almost nothing about that quality. Two products can both report $5,000 a month and be completely different businesses. One is a durable subscription base that renews itself every month with barely a nudge. The other is a leaky bucket that only looks full because the founder keeps pouring new customers in the top.

This guide is about telling those two apart. It stays in its lane: revenue quality, the code and infrastructure you inherit, and the support load that decides how passively the thing can run. For the general mechanics of finding deals, reading a listing and closing safely, start with how to buy your first digital business or the complete guide to buying a small digital business, and treat this as the software-specific layer.

What actually drives value in a micro-SaaS

The asset you are buying is not the app. It is the set of customers who have already decided to keep paying, and the likelihood that they carry on deciding that after you take over. MRR is a vanity number until you break it apart. A business growing at 10% a month sounds healthy, but if it is losing 8% of its base every month and papering over the gap with paid acquisition, you are buying a treadmill. The moment you slow the ad spend or lose the founder's audience, the real shape of the thing appears. What you want is recurring revenue that recurs on its own: customers who stay because the product is embedded in how they work, not because they forgot to cancel. So the first job is to stop looking at the top-line figure and start asking what it is made of.

Reading churn, MRR composition and cohort retention

Ask the seller to decompose MRR into its four moving parts: new revenue, expansion (existing customers paying more), contraction (existing customers paying less), and churned revenue (customers who left). A single net number hides all of this. A business can show flat MRR while quietly bleeding its best customers and replacing them with cheaper, flakier ones.

Then look at churn two ways. Gross revenue churn tells you how much you lose before any expansion is counted, and it is the honest floor. Net revenue churn counts expansion back in, and a product with negative net churn – where existing customers grow faster than others leave – is a genuinely rare and valuable thing at this size. For a sub-$150k micro-SaaS, monthly gross churn in low single digits is healthy, and anything routinely above 8-10% a month means the base resets roughly once a year.

Cohort retention is where the truth lives. Ask for a cohort table: group customers by the month they joined, then track how many are still paying 1, 3, 6 and 12 months later. You are looking for the shape of the tail. If retention falls off a cliff and keeps falling, the product has no real stickiness. If it drops in the first month or two and then flattens into a long, stable plateau, you have found a core of customers who genuinely rely on it. That flat tail is worth far more than a high headline growth rate, because it is the part of the revenue that survives you.

Assessing the tech stack and infrastructure you'll inherit

Here is the mental flip that separates good software buyers from the rest: treat the code and infrastructure as a liability you are inheriting, not an asset you are admiring. A clever architecture is not something you get to enjoy. It is something you now have to keep running.

Audit three things. First, hosting and running costs: what does it actually cost per month to keep the lights on, and is that cost already inside the profit figure or quietly subsidised by free credits that expire? Second, third-party dependencies. Most micro-SaaS is built on other people's services – a payments processor, an email provider, an auth layer, and increasingly one or more AI APIs – and each is a supplier who can change pricing or terms, or a legacy plan you will not inherit. Third, single points of failure the founder never wrote down: the one cron job on a personal server, the manual monthly export, the undocumented script that reconciles billing.

You do not need to be able to rebuild the product from scratch, but you do need to know how hard it would be if you had to. What makes software genuinely handoverable is covered in what makes a digital project transferable.

Support load: the hidden cost of running it

Support is the tax on recurring revenue, and it is usually invisible in the numbers the seller shows you. A product can look wonderfully passive right up until you are the one answering the tickets.

Measure it concretely. Ask for tickets per customer per month, response times, and where support actually happens – email, a shared inbox, a Discord, DMs. Then ask the question that matters most: how much of it depends on the founder personally? If half the tickets need someone who knows why a particular edge case exists, you are buying a job with the founder's knowledge locked in their head, not a business.

Support load caps how passively the business can run, which in turn caps what it is worth to you. A product with two tickets a week and a decent help doc is a different asset from one generating twenty tickets a day only the founder can resolve, even at identical MRR.

How micro-SaaS is priced on annual trailing profit

Price on annual trailing profit, not on a monthly multiple and not on MRR. Take the trailing twelve months of genuine profit – revenue minus the real cost of hosting, tools, dependencies and any staff or contractors – and apply a multiple. For micro-SaaS, that multiple sits at roughly 2-4x annual profit, and you should lean towards the conservative end far more often than the top.

The top of the range is for the rare case: low, stable churn, a diversified customer base, low founder dependence and clean infrastructure. Compress the multiple for the things this guide has been teaching you to find – high churn, customer concentration, heavy reliance on the founder for support or maintenance, or fragile third-party dependencies. Each of those is a reason the profit might not survive the handover, and price is where that risk gets accounted for. For how multiples differ across asset types, see revenue multiples by project type.

One caveat: if the product is under six months old, there is no trailing profit worth trusting. Value it on asset and rebuild terms – what it would cost you to build the same thing – not on a profit multiple, and be conservative about revenue that has not yet proven it repeats.

What to verify before you buy

Verify revenue at source. That means the payment processor – Stripe, Paddle, or whatever handles the subscriptions – not a spreadsheet or a dashboard the seller controls and can edit. Reconcile the processor's payout history against the bank account it lands in. A revenue claim that only exists in a screenshot is a claim, not a fact.

Cross-check the subscriber count and MRR inside the processor against the cohort and churn story you were told. The numbers should agree. Where they do not, that gap is your next question. A focused way to run this is set out in the 90-minute revenue verification session.

What breaks on transfer (and how to de-risk it)

Transfer risk in software concentrates in a handful of places: the code repositories, the domain and DNS, the payment processor account, and the customer data. The deal is not done when the money moves. It is done when every one of those is in your name and under your control.

The payment processor is the trickiest. You generally cannot transfer a Stripe or Paddle account, so you will be setting up your own and migrating subscriptions, which needs care to avoid interrupting billing or forcing customers to re-enter card details. Plan that migration before you close, not after. Repositories, domains, DNS records, third-party service accounts and any AI API keys all need to move deliberately, one by one, with the seller available to fix what breaks.

The handover: accounts, code, customers and continuity

Sequence the handover so nothing goes live in your name that you cannot yet run. Get the code, the credentials and a working local or staging environment before final settlement, so you can confirm the thing actually builds and runs outside the founder's machine. Settlement itself is cash or wire only, with funds and access changing hands in the right order through escrow.com so neither side is exposed.

Agree a short, defined support window where the founder answers your questions and helps resolve customer tickets that need their history, bounded and paid for as part of the deal rather than a vague open-ended favour. And communicate the ownership change to customers in a way that reassures rather than alarms: for a subscription business, the quiet loyalty of the existing base is the whole asset, and a clumsy transition is the fastest way to damage it.

Buy the recurring revenue that recurs on its own, inherit the infrastructure with your eyes open, and price the risk honestly. Do that, and a micro-SaaS is one of the cleaner small businesses you can own.