How to price a micro SaaS

The first price most indie founders pick has an odd source: it is the number that feels least embarrassing to say out loud.

That is how a tool that saves a consultant five hours a week ends up at $9 a month. The founder wants to be affordable. The buyer sees a cheap app with an unclear promise. Six months later, the product has too many support requests, too little revenue, and no room to improve either problem.

Pricing is not a page you finish after the product is done. It is a claim about the value of a specific result, for a specific person, delivered often enough to matter. The number comes last.

Here is how to price a micro SaaS without inventing an enterprise-style pricing maze or giving away the economics before you have learned anything.

Micro SaaS pricing starts with the job, not the competitor table

Competitor pricing is a useful boundary. It is not an answer.

If five products charge $19 a month, that tells you a buyer has seen that range before. It does not tell you whether your product creates the same outcome, carries the same cost, or belongs in the same mental category. A tool that checks a website once a month is not priced like a tool that makes a sales team faster every day, even if both appear under "AI productivity."

Start with the job you help someone finish. Then ask three questions:

1. What changes when this works? Time saved, mistakes avoided, revenue created, risk removed, or a faster decision.
2. How often does that change happen? Daily pain supports a different model than a quarterly task.
3. How does the buyer already measure the job? Per seat, per client, per document, per completed task, or simply per month.

The language should come from customer discovery, not from a marketing brainstorm. If people say they pay a virtual assistant to clean up 100 leads every week, "leads processed" is probably more natural than an arbitrary token allowance. If they say the tool replaces a spreadsheet they open all day, a simple monthly plan might be clearer.

Set the price floor before you choose the price

Every SaaS has a floor, even one that appears to be software with almost no marginal cost.

For a conventional product, list the monthly costs that increase when one more customer shows up: API usage, hosting, storage, support time, payment fees, third-party integrations, and the occasional human intervention you are pretending will not happen. For an AI product, do this with a real worst-case workflow, not an average request that makes the spreadsheet look friendly.

Then ask the more annoying question: how many customers at this price would make the business worth operating?

The table is not an instruction to charge $79. It is a reminder that a low price creates a volume business. If you are building alone, a price that requires hundreds of active customers should be a deliberate choice, not an accident made because $9 felt friendly.

The honest economics behind roastme.gg make this visible. The stack may be small, but every payment, model call, and public result still has a cost. A narrow product can use a simple price. Simple does not mean careless.

Pick a value metric people understand without a tooltip

A value metric is the thing a customer sees as usage. It should move with the benefit they receive and be easy to predict.

Common options work when they match the product:

• Flat monthly price: one person, one clear job, modest usage variation.
• Per seat: collaboration grows as more people need access.
• Per unit of work: documents, reports, invoices, sites checked, or leads enriched.
• Usage credits: variable-cost work such as AI generation, if the unit is visible and understandable.
• Hybrid: a base subscription plus overage for a genuinely expensive activity.

Avoid a metric that only exists because your database can count it. "Workflow intelligence units" might help a slide deck. It forces every customer to ask what they are buying.

There is a useful test: can a prospective customer estimate next month's bill after one sentence? If not, keep simplifying.

Flat pricing is underrated for a micro SaaS

Founders often copy the three-tier pricing page of a public company because it looks complete. Early on, it mostly gives visitors new ways to hesitate.

One price is a strong default when the product serves one narrow persona and usage is unlikely to explode. You can write a direct promise, such as "$29 a month for unlimited client follow-ups," and learn whether the job is worth $29 before you learn how to design a pricing matrix.

Two plans are enough when there is a real difference in value. Perhaps freelancers need the core workflow and small teams need shared access. Perhaps a light plan handles a weekly task while a professional plan handles a daily one. The distinction should be obvious in the person's work, not buried in a list of gated buttons.

Do not add a free plan because you are afraid to ask for money. A free tier is a product with onboarding, limits, support, abuse prevention, and conversion work of its own. It is useful when it creates a natural habit or word of mouth. It is not a substitute for a clear offer.

How to test willingness to pay before the full product exists

The cleanest test is asking someone to make a small commitment to a real outcome.

During a beta, offer a paid pilot with a defined start and end date. The price can be lower than the eventual plan, but it should not be imaginary. You are testing whether the job has enough weight for someone to put a payment method, budget line, or manager approval behind it.

You can also show a pricing page before every feature is polished. Do not pretend it is final. Say you are testing the offer, name the expected price, and ask what would make it worth that amount. The best answers are not "I would pay less." They name the missing result, objection, or alternative you need to beat.

Bad tests include surveys that ask "would you pay $20?" People are guessing about a future version of themselves. Better questions are:

• What do you use now, and what does it cost?
• Who would approve a purchase like this?
• What would need to happen for you to replace the current workaround?
• Is this a monthly expense, a project expense, or something you would only use once?

Those questions show you how a price will be evaluated, which is more useful than a forced yes or no.

Do not discount before you understand the objection

An early discount can be fair. It rewards people who accept the risk of an unfinished product. A permanent pile of discounts is different. It hides whether the product is hard to understand, too expensive for the outcome, or simply not wanted.

When a prospect says the price is high, ask what they are comparing it with. If the answer is a spreadsheet they made themselves, your product has to save enough time or error to beat a free workaround. If the answer is an assistant, agency, or paid tool, you have a more concrete value anchor.

The response is rarely "offer a coupon." It is often one of these:

• sharpen the promise so the outcome is visible;
• reduce the risk with a pilot or clear cancellation path;
• change the value metric to match the buyer's workflow;
• remove features that make the plan look like a generic bundle;
• accept that you targeted the wrong segment.

Price AI features for the bad month, not the demo

AI makes underpricing easy because a demo can look almost free. The bill appears when an active customer sends large files, retries a job, shares an account, or turns a feature into their daily workflow.

Map one valuable customer action from click to result. Count every model call, tool call, input, output, retry, storage event, and human rescue. Add a buffer. Then put a sensible limit around the part of the product with variable cost.

This does not mean you need a complicated credit economy. You might offer a flat plan with a clear fair-use boundary, or bundle a visible number of reports. The customer needs to understand the rule before the invoice surprises them. You need to know that an enthusiastic user is not your most expensive customer by accident.

For a deeper look at choosing a model by task shape rather than prestige, the GPT-6 Astra cost guide is a useful companion.

When should you raise prices?

Raise prices when you can state, in one sentence, why a new buyer gets more value than the buyer from six months ago. That could be a clearer outcome, a workflow you now handle end to end, reliability that removes manual work, or a new audience with a larger budget.

Do not wait until your support load becomes unbearable. That is usually a sign the price was too low for the operating model from the beginning.

Keep existing customers on their deal for a reasonable period if they took the early risk. New prices are easier to test with new buyers. The goal is not to surprise loyal people. It is to learn whether the next version of the promise supports a healthier business.

A one-page pricing worksheet

Before you publish a pricing page, fill in this small worksheet:

If the answers are vague, the pricing page will be vague too. Go back to the calls, not the colour of the pricing cards.

Frequently asked questions

How much should a micro SaaS cost?

There is no standard number. Set a price from the value of the job, the buyer's current alternative, your cost to serve an active customer, and the number of customers you can support. A simple $29 plan can be perfect for one product and fatal for another.

Should micro SaaS products have a free plan?

Only when free use creates a natural path to paid value and you can support it. A free plan is not required for early traction. A paid pilot with clear onboarding often produces better feedback.

Is usage-based pricing good for AI SaaS?

It can be, when usage maps to a result the customer understands. Do not charge in invisible units just because your own costs vary. Use a base plan, a clear allowance, or a visible unit of work.

When should I show pricing on my landing page?

Show it once you know the basic offer. Hiding a price rarely fixes a value problem. It usually creates a harder conversation later with people who were never in range.

The honest summary

Good micro SaaS pricing is not about finding the most clever tier names. It is knowing the job you make easier, the cost of delivering that job, and the small group of people who will pay to stop doing it the old way.

Start with one clear offer. Test it in real conversations. Keep the value metric simple enough that nobody needs a calculator to understand it. Then change the price when you have evidence that the promise got stronger, not because another founder's screenshot made you nervous.

When you are ready to put that offer in front of more people, submit your product on makers.page. A clear price and a clear description make a directory listing much easier to trust.

Related reading:

• The honest economics of roastme.gg
• Customer discovery questions for startup founders
• How to find beta testers for your SaaS