In this piece · 6 sections
Same profit, very different price
Two products earn the same monthly profit. One sells for a multiple that makes the owner grin; the other sells for a fraction of it, and the owner never understands why. The difference is almost never the quality of the code or the polish of the interface. It is the shape of the revenue underneath — whether it recurs on its own or has to be re-won every single month.
That is the whole story of web app versus SaaS valuation. "SaaS" and "a web app" are often used interchangeably in conversation, but a buyer prices them as different asset classes. One is an annuity. The other is a sequence of sales you have to keep making. At the same profit, the annuity wins, and it wins by a wide margin.
This post is about the boundary line itself. If you want the full mechanics of the SaaS lens — ARR versus SDE multiples and the metric levers — that lives in the SaaS valuation pillar. Here the question is narrower and more useful: is what you built actually a SaaS, and if not, what is that costing you when you sell?
What actually separates SaaS from a web app
The word "app" describes how something is built. "SaaS" describes how it is paid for. A web app is any software you reach through a browser — a converter, a generator, a dashboard, a tool. It becomes SaaS only when customers pay for it on an ongoing subscription and keep renewing. The delivery is the same; the business model is not, and the business model is what a buyer values.
Plenty of genuinely useful web apps are not SaaS in the valuation sense. A one-time-purchase tool, a free app that earns from display ads, a utility billed per transaction or per use, a lead-generation site that sells the leads — all of these are real businesses. But none of them have a signed-in, billed-monthly base that renews without being re-sold. That base is exactly what the SaaS multiple rewards.
None of this is a judgment about which is the better product to build. It is simply how a buyer reads the asset. The same software, sold as a subscription instead of a one-off download, moves across this line — and the multiple moves with it. The next sections explain why the move is worth so much, and how to make it.
Why recurring revenue lifts the multiple
A multiple is a risk score wearing a number's clothing. The lower the risk that the revenue disappears, the higher the multiple a buyer will pay. Recurring subscription revenue scores well on exactly that test, because a customer who paid last month and is still subscribed is very likely to pay again. Predictable revenue is low-risk revenue, and low-risk revenue commands a premium.
Retention is the second lift. When subscribers stay — and especially when they upgrade over time — revenue grows without a single new sale. A buyer treats that as the closest thing online software has to an annuity. The detail of how those metrics feed the number lives in the SaaS valuation pillar; the point here is simpler: retention is what makes "recurring" real.
There is also a method effect. Larger, growing SaaS is often priced on its recurring-revenue stream directly, while small subscription tools are priced on the cash the owner keeps — the micro-SaaS valuation guide walks that small-end case. Either way, the recurring base is the engine. A web app without it simply has less for a buyer to underwrite.
This is also why monthly recurring revenue is treated as the headline metric for subscription software — our MRR-based valuation explainer goes deeper on how that figure anchors the math. For a web app with no MRR, there is no equivalent anchor, which is part of why its band sits lower at the same profit.
What drags a web-app multiple down
If recurring revenue is the lift, three things are the drag — and most non-SaaS web apps carry at least one. Each is the same problem in a different costume: the revenue is not durable, so a buyer cannot count on it surviving the handover. Understanding the drag is the first step to removing it.
One-time revenue is the first. A product sold as a single purchase has to find a brand-new customer for every dollar — last month's sale does nothing for this month. A buyer inherits an empty pipeline they must keep filling, so they discount for the constant re-selling that the model requires.
Churny or usage-based revenue is the second. Even when there is billing, if customers drift away quickly or only pay when they happen to use the tool, the income behaves more like a series of one-offs than a subscription. The word "recurring" only earns its premium when the customers actually recur.
Ad-dependence is the third, and the quietest. An app that earns from display ads does not control its own revenue — a CPM market and a platform's policies do. That income can be cut without notice, which is exactly the kind of risk a careful buyer prices aggressively. It can also collide with platform terms; our work on vendor and platform dependence covers why a revenue line you do not own is a weak one.
How revenue shape pulls the multiple, at the same profit
Moving a web app toward SaaS economics
The encouraging part is that the line between web app and SaaS is one you can cross deliberately. You do not need to rebuild the product. You need to change how it gets paid for and how hard it is to leave — and you usually want to start months before a sale, so the new pattern has a track record by the time a buyer looks.
There is a final, unglamorous lever: make the thing transferable. A subscription business a buyer cannot operate after you leave is worth less than its revenue suggests. Documented operations, a clean handoff, and revenue that does not run through your personal accounts all protect the multiple — and they are the same fixes the SaaS guides recommend, because they apply the moment recurring revenue exists.
Turning the distinction into a range
Knowing whether you have a web app or a SaaS tells you which way the multiple leans, but not the number. Every factor above interacts — strong retention can rescue a modest profit; ad-dependence can sink a strong one. Holding all of that in your head produces a gut figure, and a gut figure is the one thing a buyer will not pay for. The job is to turn each signal into a defined input and let the math combine them.
That is how Real Site Worth approaches it. The revenue shape, retention, and dependence signals are scored into deterministic inputs; the model picks the right lens for the size and revenue profile and returns a banded range. We are deliberate about one thing: the AI never invents the number — the range is computed in code, and the written explanation is the part that gets narrated. A figure you cannot trace is a figure a buyer discounts.
The practical takeaway is the same whichever side of the line you are on. If you have a SaaS, protect the retention that earns the premium. If you have a web app, the fastest way to raise its worth is to give it the one thing it is missing — durable, recurring revenue you control — and then read the range against the SaaS guides to see how far that move can carry you.
