How to price a micro SaaS: the model, the floor, the first number

Pricing advice for small software is either enterprise value-pricing theory or "charge more" as a slogan. The solo founder's question is a different one: not what this is worth, but whether there is any price at which one person can carry the customers that price requires. At $3,000 a month that question has a floor, and it sits higher than most people set their first price.

Three verdicts, and what each is worth

The analysis returns one of three things about a price, and each maps to a fixed number on the scorecard:

The middle one is the one to sit with. Acceptable means you can charge enough and have nothing spare — no room for a bad month, a refund run, or the customer who turns out to cost four times the average. Most first prices land there and get read as a pass.

The floor, and where it comes from

The contract defines a low-ticket trap: an idea structurally stuck below roughly $19 a month, or $100 once. When that is true the analysis says so and names the reason, rather than proposing a price it does not believe in.

Be clear about what that threshold is. It is a judgement written into a prompt, not a measurement — a line drawn by a person who had seen enough one-person products to have an opinion. On its own it would be worth very little, and you should treat any pricing floor you read anywhere the same way.

What makes it interesting is what happens when you put it next to arithmetic that knows nothing about it.

The two rows at or below the pricing threshold are exactly the two rows in the heavy support band. Past eight hours a week support is not a cost of the business, it is the job — and that is where the pricing line falls, without either half having been told about the other.

Now the honest limit on that, because it is the kind of coincidence people quote badly: both halves are ours. A prompt rule agreeing with a calculator we also wrote is internal consistency, not external validation. What makes it worth publishing is only that the two were authored separately for different purposes, and neither was tuned to the other.

What the price is anchored to, and why it is a closed list

Before a number, the analysis has to name what the price is tied to. The set is closed on purpose:

• revenue
• time_savings
• cost_savings
• status
• other

The first three are the ones you can defend in a sentence to a stranger — this makes you money, saves you hours, or cuts a bill. If the honest answer is the fourth, you are selling a feeling, which sometimes works and never works predictably for one person with no brand. And if the answer is the fifth, the price is a guess wearing a rationale.

Two rules that keep the number honest

Comparators cite a source or say UNKNOWN. A competitor's price is a fact about the world, and the contract forbids inventing one — every comparator carries a real URL or the tier is marked unverified. This is the single most common lie in pricing research, and it is convincing because plausible prices are easy to generate.

The model is not allowed to do the arithmetic. The customers-needed calculation is explicitly forbidden to the model and done in code instead. That is not a performance decision. A division is the one part of this that has a right answer, and handing a right answer to something that samples is how you get a page of confident numbers that do not add up.

How to set the first price

Start above the floor, not at it. Your first price is a hypothesis, and the cheapest one to test is the one that leaves you room. Dropping a price later is easy; raising it on existing customers is the conversation nobody enjoys.

Price the outcome, not the artefact. What the buyer gets back is the anchor. The number of features is not.

Then run the two numbers. Take your price to the customers-needed calculator, take the answer to the support-hours one, and look at the week that comes back. If it does not fit, the price is wrong before the product is.

Or run the same reading on your own idea. Pricing Power, one of the analyses on an idea's page once its main check is done, names a price, the tiers and an entry offer, and says whether the idea is stuck below the floor. It costs 1 credit, and the 2 credits every new account starts with cover the main check and this one.

Flat, tiered, per seat or usage: pick the model your week can carry

Flat. One price, one plan. The easiest to explain and to support, and the right default for a first version: every customer asks the same questions, so your support minutes stay predictable.

Tiered. Two or three plans that differ by limits, not by features you maintain twice. Each tier is one more thing to explain on the pricing page and in support replies, so add the second tier when buyers ask for it, not before.

Per seat. Revenue grows with the buyer's team while the account count stays the same, so the target is divided by a bigger number without the headline price moving. It fits a tool several people in one company use, and it adds a seat-management screen and the questions that come with it.

Usage. The bill follows what the customer consumes. Fair, but neither you nor the buyer can predict the monthly number, and a surprising invoice is a support ticket. Keep it for products whose own cost to you moves with usage.

A free plan is support you are not paid for

Free users ask questions too. Take 300 of them at 5 support-minutes a month each — example inputs, put in your own — and the same calculator returns about 5.8 hours of support a week before one of them has paid. By the bands a solo week is measured against, that is a real share of it, spent on people who may never convert.

A trial with an end date caps that cost; a free plan with no end does not. If you offer one, make it self-serve enough that its users never need you, and count its minutes in the support calculator the same way you count a paying customer's.

Test the price before you build

A price is a guess until someone pays it. Put it on a landing page with a pre-order or a paid pilot, and write the pass mark down before the page goes live: how many payments, from how many visitors, by what date.

If nobody pays, dropping the price is not the easy fix it looks like. On the table above, the rows at or below the floor are the ones where support alone passes 8 hours a week — a cheaper price that sells has swapped a demand problem for a capacity one. The whole ladder, from praise to payment, is in will people pay for your idea?

Monthly or annual, and when to raise the price

Start monthly. Annual plans bring cash forward and give a customer one renewal decision a year instead of twelve, but they also lock in a price you have not tested — and a refund conversation if it was wrong. Add annual once a few customers have renewed month to month, with a discount for paying upfront.

Raise the price when new customers stop pushing back on it. Raise it for new customers first and leave existing ones where they are for a while. Either way the arithmetic works in your favor: every step up lowers the number of customers your target needs.

The short version

• Three verdicts, and none of them is "too high". A solo product does not usually fail by charging too much.
• "Acceptable" means enough with nothing spare. Read it as a warning, not a pass.
• The stated floor is about $19 a month or $100 once — a prompt's judgement, and it lands exactly on the two rows where support alone eats a solo week.
• Both halves of that agreement are ours. Internal consistency, published as such.
• A comparator without a source is marked unverified, and the division is done in code, because it is the one part with a right answer.
• Pick the model your week can carry: flat first, a second tier when buyers ask for it, per seat when several people use the tool, usage only when your own costs move with it.
• A free plan is support nobody pays for, and a trial with an end date caps it. Test the price with a pre-order or a paid pilot before you build, and start monthly.