Is SaaS passive income? Recurring is not the same as passive
· Zero to Hundred
No. Recurring revenue and passive income are two different things, and the subscription model gives you the first one specifically because you keep supplying the second half of the bargain.
That is not an argument against building a SaaS. It is an argument against expecting it to be passive. The alternative worth knowing about is not passive either. What it is, 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 actually 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.
None of that makes subscriptions a bad business. It makes them a job. A job with good economics if it works, but a job you cannot stop doing without the revenue stopping too.
Is selling the codebase passive instead?
No, and anyone telling you otherwise is selling a course.
The useful distinction is not passive versus active. It 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 | An evaluation window, then nothing |
| Fixed costs | Hosting and tooling, monthly, forever | None once the build 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. That is a genuinely different arrangement, and it is the one most people never consider because the whole conversation defaults to MRR.
Can you sell the same codebase more than once?
Yes, and this is the part that gets missed.
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 build can produce many sales. It is not a subscription and it is not guaranteed income. It is repeat income from work you did once. Several Buyers can be evaluating the same listing at the same time.
The same developer above reports a catalogue of 27 products, their best performer a $25 component pack that has passed 200 sales. That is one build, sold two hundred times. No hosting bill, no churn, no support queue for a live service.
What does that income actually look like?
Smaller than a good SaaS month, and it starts sooner.
His 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 catalogue 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 the next build rather than into keeping the last one alive.
Be clear-eyed about the shape. Sales are lumpy and unpredictable month to month. A single listing decays as its dependencies age. The catalogue 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 is the question the passive-income posts skip entirely, and it is the one that decides whether the obligation really ends.
For sales at or above $100, payment sits in escrow while the Buyer evaluates the software in your test environment for 7 days. They can dispute during that window on four factual grounds: a broken test environment, misrepresentation, a bug that blocks evaluation, or other factual grounds. The code is released and you are paid when they confirm, or when the window closes without a timely dispute.
Below $100, the Buyer receives the code immediately and has 24 hours to report misrepresentation or a bug that stops the software working. Your payout is held for 72 hours so a report filed in time can be reviewed. A limitation you disclosed in the listing is not valid grounds.
A completed sale carries an 8% platform commission. 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 the value is in the running service, not the code. 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 catalogue of licenses does not. If you are building something to sell as a company later, MRR is the point.
When you actually 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 three 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? Be honest. Most side projects fail this one, which is why so many of them quietly die 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 is 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 actually goes wrong is the honest version from the other side.
