How to price a micro-SaaS

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

Price your micro-SaaS on the value it creates for the customer, not the hours you spent building it — then pick a number that makes you slightly uncomfortable, because almost every solo founder's first price is too low. Charge from day one instead of running a permanent free tier, keep tiers to two or three, and treat your launch price as a hypothesis to revise within weeks, not a promise you owe forever.

Disclosure: this guide is published by SoleOS, a portfolio dashboard for solo founders running several products — nothing below requires our product.

Value-based, not cost-based

Cost-based pricing asks "how many hours did this take me, plus a margin?" — the instinct almost every technical founder reaches for first, and the wrong question. Your customer doesn't care whether a feature took a weekend or three months; they care what it's worth to their business or their life. A tool that saves someone two hours a week, replaces a paid tool they already use, or removes a task they'd otherwise hire out has a value ceiling usually far above what it cost you to build. Price against that ceiling: what does this replace, what does it save, what would a person cost to do instead? The answer is almost always bigger than your gut says.

Charge from day one

Free-forever tiers feel safer, but they don't validate anything. A user who pays nothing "uses" your product in ways that tell you little about whether it solves a real problem — sign-ups pile up, engagement looks fine, and none of it means someone would open their wallet. A trial (even a short one, card required) filters for people who actually have the problem, and every trial-to-paid conversion is a real signal. If you're still chasing your first paying customers, the mechanics are covered in how to get to your first $100 MRR — the short version is: put a price in front of people before you've "finished" the product, not after.

Your first price is (almost) always too low

There are a few reliable reasons for this. Founders anchor to their own willingness to pay, a bad proxy — you're not your customer, and you're also the person who knows every flaw in the product, which makes you discount it in your own head. Founders also underweight the time and risk they're removing for the customer relative to the cash cost, since the hours you spent building it feel small next to the value it delivers to someone else. And there's a simple fear of rejection: a lower price feels like a safer ask.

Don't agonize over the "right" number before launch — you can't know it yet. Treat the first price as a starting point, and raise it on new signups the moment you have any signal that people are converting easily or not pushing back on cost. If nobody has ever hesitated at your price, that's information, not a compliment.

Keep tier design simple

Two tiers is fine; three is usually the ceiling for a solo-run product. Every extra tier adds a decision the customer has to make, and indecision is the enemy of conversion — a confused visitor doesn't pick the "wrong" tier, they leave. Gate tiers on one or two dimensions that map cleanly to value: seats, number of projects, a feature set that unlocks at scale. Avoid gating on things customers can't predict in advance (API calls, storage) unless usage is core to what you sell — unpredictable limits create support tickets and surprise bills that cost more than the extra tier earns.

The $20–$99/mo band, and why it's common

A huge share of indie SaaS lands somewhere in $20–$99/mo, for structural reasons, not arbitrary ones. Below roughly $20/mo, the price often doesn't cover the support and infrastructure burden of running a product solo — you need a lot of customers just to break even on your own time. Above roughly $99/mo, you're usually competing with tools that have sales teams and proof of ROI at a company level; an indie tool without those things struggles to justify the number without a genuinely large, quantified value story.

In between, you're pricing at a level an individual or small team can approve on a card without asking anyone, but high enough to fund a sustainable business on a few hundred customers rather than a few thousand. That's the band — not a magic number, but a match to how small businesses and individuals actually spend on tools.

Annual plans — and when to offer them

Annual plans solve a cash-flow problem for you and a hassle problem for the customer, in exchange for a discount versus paying monthly. Offer one once you have enough monthly cohort data to know your typical customer sticks around past the first couple of months — an annual discount on a product with high early churn just locks in a refund headache or a discount you didn't need to give. Until then, monthly-only is fine, and arguably safer: it keeps your churn number honest instead of hidden behind a 12-month commitment.

Raising prices: test on new customers, grandfather the rest

You will raise prices — a first price that never changes usually means it was priced right by accident, or the business stalled. The safe way to do it: apply the new price only to new signups, watch conversion for a few weeks, then decide whether to roll it further. Never silently change what an existing subscriber is billed — that's a trust problem, not a pricing experiment. Instead, grandfather existing customers at their current price, or give them a long, clearly-communicated notice period; they didn't sign up for a higher number, and forcing it on them retroactively is the fastest way to spike churn right when you're trying to grow revenue per customer. Running multiple products? Test per app rather than copying one formula across the portfolio — what a tier converts at on one app says little about another with a different audience. If this is part of a broader push past an early plateau, see growing from $100 to $500 MRR.

Price vs. packaging — they're not the same lever

Price is the number. Packaging is what the customer gets at that number — which features are gated, what the usage limits are, what separates each tier. A lot of "pricing problems" are actually packaging problems: the conversion issue isn't that $29/mo is wrong, it's that the trial gives away the one feature that would've made someone upgrade, or the top tier bundles things nobody asked for. Before touching the number, check whether moving a feature between tiers fixes it more cheaply than a price change would.

What to actually measure

Two things matter, and neither requires guessing. First, conversion by price point: if you test more than one price, compare trial-to-paid conversion at each, not just total revenue — a higher price with slightly lower conversion can still win on revenue per visitor. Second, willingness-to-pay signals from real conversations: when a trial doesn't convert, ask why; when someone upgrades, ask what tipped it. Those conversations tell you more than a dashboard about what you're actually being paid for. Guidance on wiring up revenue tracking across several products is in how to track revenue as a solo founder; the metrics dictionary covers specific numbers worth watching per product.

If you run one product on one Stripe account, you don't need a portfolio tool to see conversion by price point — Stripe's own dashboard or a spreadsheet does that fine. A tool like SoleOS earns its keep once you're running several products and want that same view side by side without opening five dashboards — useful, not mandatory, and not the only way to do this well.

Frequently asked questions

How do I know if my price is too low?

Watch for signals instead of waiting for certainty: near-zero pushback at checkout, a trial-to-paid conversion rate that's unusually high with no drop-off, or customers expressing surprise at how cheap it is. Any of those is a reason to test a higher price on new signups, not a reason to celebrate.

Should a micro-SaaS ever have a free plan?

A time-limited trial is almost always better than a permanent free tier for a solo-run product, since free users still cost support time and infrastructure without ever becoming revenue. A free tier can work if it's genuinely limited in scope (not just usage-capped) and drives word-of-mouth or top-of-funnel for a much larger paid audience — but for most single-founder tools, the support burden isn't worth it.

How many pricing tiers should I have?

Two or three. More adds decision friction for the buyer without adding much revenue, since customers cluster around one or two "obvious" choices anyway. If you find yourself designing a fourth or fifth tier, it's usually a packaging problem, not a pricing one — reconsider what's gated where instead.

When should I introduce annual pricing?

Once you have enough monthly customer history to know churn in the first few months is low. Offering annual billing before that risks discounting revenue from customers who wouldn't have stuck around anyway, and creates refund conversations you don't want to be having solo.

Do I have to keep my launch price forever?

No, and you shouldn't expect to. Treat the first price as the start of a testing process, not a final answer. Raise it on new signups once you have evidence people aren't hesitating, and grandfather existing customers when you do so trust with your current base stays intact.