Is SaaS passive income? Recurring is not the same as passive
No. Recurring revenue and passive income are 2 different things, and the subscription model gives you the first one specifically because you keep supplying the second half of the bargain.
Build a SaaS if you want one. Do not expect it to be passive. The alternative is finite. You finish a codebase, license it to Buyers who want it, and your obligation closes on a defined date instead of renewing every month.
What does a subscription commit you to?
To showing up, indefinitely, for as long as the money arrives.
Recurring revenue is a promise you renew every month. In exchange for the payment you owe uptime, support, security patches, dependency upgrades, and a hosting bill that arrives whether anyone subscribed or not. One developer writing up their own experience puts the floor at $50 a month in infrastructure before a single paying user, alongside 4 months of building that produced 3 signups and $0 in the first month (DEV).
Then churn. Recurring revenue only stays recurring if you keep replacing the people who leave, which means marketing is also permanent. The developers asking whether passive SaaS income is possible are usually discovering this part: the Indie Hackers thread on it and an Ask HN from 2015 are the same question a decade apart, and the answers have not improved.
That makes a subscription a job. The economics can be good, but the revenue stops when you stop.
Is selling the codebase passive instead?
No.
The useful distinction is ongoing versus finished.
| Subscription | Licensing a finished codebase | |
|---|---|---|
| Income shape | Predictable, compounding while it lasts | Lumpy. Depends on demand and on listing more than once |
| What you owe after payment | Uptime, support, patches, upgrades, indefinitely | A 24-hour report window, then nothing |
| Fixed costs | Hosting and tooling, monthly, forever | None once the software is done |
| Marketing | Permanent, because churn is permanent | Per listing |
| When you stop working | Revenue stops | Existing sales are already settled |
| Ceiling | High if it works | Bounded by how many people want this specific thing |
Neither column is free money. The right column is money for work you already finished. Most people never consider it, because the conversation defaults to MRR.
Can you sell the same codebase more than once?
Yes.
A license is not a transfer of ownership. On Zero to Hundred a Buyer purchases a non-exclusive, worldwide, perpetual license to use, modify, and deploy the software for their own purposes. The Builder keeps the copyright and can license the same software to other Buyers. Buyers cannot resell, re-list, or redistribute it as a product, which is what protects the thing you built from being turned into your competition.
So one piece of software can produce many sales. The income repeats, from work you did once, and it is not guaranteed. Several Buyers can buy the same listing.
The same developer above reports a catalog of 27 products, their best performer a $25 component pack that has passed 200 sales. That is one piece of software, sold 200 times, with no hosting bill or churn.
What does that income look like?
Smaller than a good SaaS month, and it starts sooner.
Their numbers: $200 in the first month, $180 in the second, against a SaaS attempt that produced $0. They estimate needing 100-plus paying subscribers to match what the catalog earns, and spend roughly 2 hours a week on support versus 15 hours building new products. That ratio is the actual product of the model. Your hours go into building the next one rather than into keeping the last one alive.
Sales are lumpy and unpredictable month to month. A single listing decays as its dependencies age. The catalog is what carries it, which means the model rewards people who ship repeatedly and punishes people who list one thing and wait.
What do you still owe a Buyer after the sale?
A defined window, and then the sale is closed. This question decides whether the obligation ends.
Every sale is final, at every price. The Buyer receives the source the moment they pay and has 24 hours to report a factual problem on 3 grounds: misrepresentation, a bug that stops it working, or other factual grounds. Your payout is held for 72 hours so a report filed in time can be reviewed before any money reaches you. A limitation you disclosed in the listing is not valid grounds.
A completed sale carries a commission on your side: 25% on a marketplace sale, or 8% plus $0.50 on a sale you brought yourself. After the window, that Buyer's purchase is settled and you owe them nothing further. Compare that to a subscriber, who is owed something every month for as long as they stay.
When is a subscription still the right call?
Often. This is not a case where one model wins.
When people pay for the running service. If what people pay for is your uptime, your data, or your network, there is nothing to license. Build the SaaS.
When you want a compounding asset. Recurring revenue builds an enterprise value that a catalog of licenses does not. If you are building something to sell as a company later, MRR is the point.
When you enjoy operating it. Some people like the support queue and the metrics. That is a real preference and it makes the ongoing obligation cheap for them.
When you cannot hand the code over cleanly. Keys tied to your accounts, third-party terms that block redistribution, infrastructure that is not reproducible. Fix that first or do not list it.
How to decide
Ask 3 questions about the specific thing you built.
- Would someone pay for this if they had to run it themselves? If the answer is no, the value is in your operation, and licensing is the wrong model.
- Do you want to still be maintaining this in 18 months? Most side projects fail this one, and then sit unused instead of being sold.
- Can a stranger clone it and get it running from your README? If not, that is an afternoon of work standing between the code and every sale it might make.
Two yeses and a fixable third make a listing. If you already know you are done maintaining something, what to do with an app nobody uses covers the decision in more detail. When you are ready, listing from anywhere is the mechanics, and the Terms of Use has the license language in full. If you are buying rather than selling, what goes wrong covers the other side. For the wider picture of who buys and sells here, who is Zero to Hundred for lays it out.
