Micro SaaS Pricing: How to Set Your First Price
· 6 min read · Guides
Start with one flat monthly price, set a little higher than feels comfortable, and treat it as version one. Base it on what your product saves or earns the customer, not on how long you spent building it. Then change it once real buyers give you data.
That's the short version. Below are the steps, a quick way to sanity-check your number, and a prompt you can paste into your AI editor to do the grunt work.
Why your first price matters more than you'd like
Vibe coding makes the building part fast, so pricing is often where a project stalls. You can ship a working app in a weekend and then spend three weeks staring at a pricing page.
Part of the problem is that the first price is sticky. You can always add a cheaper tier later, but raising prices on existing users is far harder. That's the strongest argument for starting a bit higher than your gut says.
It also helps to remember that it's a first draft. Treat the first number as a baseline to test and revise, not a permanent decision.
Step 1: Price the outcome, not the build
Write one sentence: "This tool saves [who] about [X] every [week/month] by doing [Y]." If you can't fill that in, you don't have a pricing problem yet. You have a positioning problem.
Price on the value the product saves or earns for the user, not on the hours you spent building it. A tool that saves a freelancer two hours a month can sit well above "coffee money". A tool that's a nice-to-have for hobbyists can't.
Be honest about the buyer, too. A business expensing a tool thinks about price differently from someone paying out of pocket.
Step 2: Pick the simplest model that fits
Stripe's docs list the standard patterns. They cover flat rate, per-seat, usage-based, tiered, package, volume, and variable models. You don't need most of them on day one.
| Model | Use it when | Watch out for |
|---|---|---|
| Flat rate (one plan) | One core job, similar value for every customer | Heavy users pay the same as light ones |
| Tiered (2–3 plans) | Customers clearly differ in size or needs | More choices to explain and maintain |
| Per-seat | Value grows with team size | Pointless for solo-user tools |
| Usage-based | Cost and value scale with consumption (API calls, credits) | Needs metering; revenue is harder to predict |
If you don't have an obvious usage metric, start with flat pricing. Fewer options also mean fewer decisions for the visitor.
One caveat if your app calls an LLM on every action. Your costs scale with usage, so check what a heavy user costs you before promising "unlimited". A monthly cap or included credits is a common fix. You don't need to build metering for it on day one.
Step 3: Find your starting number
Here's a quick way to get a number you can defend.
- List 5–10 alternatives. Note what they charge and what's included. You don't need to be cheaper, you need to be clearly different. Include spreadsheets and "do it by hand" as competitors.
- Estimate the value. Hours saved times what those hours are worth to the buyer.
- Do your floor math. Payment fees, hosting, AI/API costs per active user, and your support time. The price must clear that with room to spare.
- Pick a number inside the range. Above the floor, well below the value.
On what's typical, the sources disagree. One roundup says most small subscription products charge $19–$49 a month, with $29 the most common first price. Another says the 2026 sweet spot for most micro SaaS is $79–$149 a month. Both are secondary sources with their own methodology, so use them as a sanity check on your range, not as rules.
The one point they agree on is that very low prices are risky. One guide warns that pricing as low as $5 a month attracts non-serious users who might waste resources. Cheap users can still ask for a lot of support.
A quick price check with real people
If you can reach 10–20 people in your niche, ask four questions. They come from the Van Westendorp method, in which you ask at what price the product is too expensive to consider, so cheap that quality seems poor, getting expensive but still thinkable, or a bargain.
Don't treat the answers as a price. People don't spend money in a survey. Use them as a range, then test inside that range with real checkout traffic.
Step 4: Keep the pricing page boring
For a first launch, you need less than you think.
- One plan, or at most three.
- Monthly price, plus an annual option if you want one.
- A clear line on what's included and what's capped.
- A way to pay that works. A working Stripe checkout beats a clever page.
If you do offer three tiers, make the middle one the plan you expect most people to take. Put the highest plan first if you want it to anchor the others, as Freemius suggests.
A free trial or freemium plan is optional. A trial works best when the product is used often, because if the product isn't sticky, trial users churn quickly. If your tool gets used once a quarter, consider charging from day one and offering a refund window instead.
A prompt to paste into your AI editor
Use this in Cursor, Claude Code, or whatever you work in. Fill in the brackets with real numbers. Then check its math, because models will happily invent competitor prices.
I'm pricing my first micro-SaaS. Help me think it through. Don't invent
competitor prices; if you don't know, say so and ask me.
Product: [one sentence]
Customer: [who, and are they paying personally or expensing it?]
Core outcome: [time saved / money earned per month, my best guess]
My costs per active user per month: [hosting, AI/API, email, etc.]
Alternatives I found: [name + price, from my own research]
Do this:
1. Calculate my break-even price per user, including payment fees.
2. Suggest 3 candidate prices with one-line reasoning each.
3. Recommend one plan structure (flat, tiered, usage) and say why.
4. Write the 4 pricing questions I should ask 10 target customers.
5. List what I should measure for 30 days before changing the price.
Step 5: Launch, watch, then raise the price
Pricing isn't a one-time call. Many successful SaaS products adjust pricing several times in their first year, based on conversion data and feedback.
Track a few numbers: how many visitors reach checkout, how many pay, how many cancel in the first two months, and what a heavy user costs you. Try new prices on new customers first, and track churn, MRR, and ARPU.
If nobody ever objects to your price, it's probably too low. If lots of people bounce at checkout, check your positioning before you cut the price. And when you do raise it, ship something customers asked for first, then announce the increase. Existing customers can stay on their current price for a while if you'd rather be gentle.
Common mistakes
- Pricing from your costs only. Costs set the floor, not the price.
- Launching with five tiers. You don't have enough customers to know what the tiers should be.
- Discounting to get early users. It attracts the wrong people, and the discount is hard to remove.
- Ignoring AI costs. "Unlimited" plus a model API is how a good month becomes a loss.
- Never revisiting. Put a reminder in your calendar for 60 days after launch.
FAQ
How much should I charge for my first micro-SaaS?
There's no single answer. Published rules of thumb range from the low tens of dollars a month to a couple hundred, depending on who you ask and who the buyer is. Work out your cost floor and the value to the customer, then pick a number between them. Business buyers can usually pay more than hobbyists.
Should I start with a free plan?
Only if you have a reason beyond "everyone does it". Free users cost you hosting and support time. A short trial, a money-back guarantee, or a free launch period for early feedback can be cheaper ways to lower the barrier. One guide suggests a free period in crowded app marketplaces to collect reviews.
Can I change my price after launch?
Yes, and you probably will. The safest way is to test new prices on new signups first and watch your cancellations. Raising prices on existing users is harder than adding a cheaper tier later, so lean higher at the start.
Cover photo: Bernd 📷 Dittrich on Unsplash