Micro SaaS ideas: the arithmetic that decides them

All guides

Micro SaaS is not small SaaS. It is a business shaped so that one person can run it indefinitely, and that shape is decided by two numbers that pull in opposite directions: how many customers your price requires, and how many hours those customers cost you.

Get the first one wrong and you never reach the income. Get the second wrong and you reach it and then cannot keep it.

The first number: how many customers your price requires

This is division, not strategy. At a flat monthly price, the customer count your target income needs is fixed the moment you choose the price.

Say you want $3,000/month at $29/month. That is 104 customers — every month, net of churn, forever.

The number itself is unremarkable. What it does to the rest of the plan is not:

• It sets your acquisition problem. 104 paying customers is a real audience, and you have to reach them repeatedly because some leave every month.
• It sets your churn tolerance. At 104 customers, five per cent monthly churn means finding roughly 6 replacements a month before you grow at all.
• It is the cheapest lever you have. Doubling the price halves the customer count. Nothing else in the business moves this number that far, which is why pricing power is not a detail.

The second number: what those customers cost you in hours

Now the part that gets skipped. Every customer consumes some support time — questions, edge cases, billing, the occasional bug that only they hit. Call it minutes per customer per month, and it multiplies by the count you just derived.

At 15 minutes per customer per month, 104 customers is 26 hours a month — about 6 hours a week, before you write a line of code.

The bands that matter for one person are not arbitrary; they come from what a solo week can absorb:

• Under 2 hours a week — light. Background noise. The business runs while you build.
• 2 to 8 hours a week — moderate. A real share of your build time is now support. Survivable, but it is the difference between shipping monthly and shipping quarterly.
• Over 8 hours a week — heavy. Support is the job. This is where a product quietly turns into a service business you did not choose.

The example above lands in the moderate band. Change any of the three inputs and it moves — which is the point, and why both calculations are on the site as tools you can run against your own numbers rather than mine.

Why the two numbers fight

Here is the squeeze that defines the category.

Lowering the price raises the customer count, which raises total support hours. Raising the price lowers both — but a higher price demands a buyer with a budget, which usually means a business customer, which usually means more support per customer, not less.

So the two obvious moves each trade one constraint for the other. The combinations that actually work are narrower than they look:

• Higher price, low touch. A product that solves one expensive, well-defined problem for a business, with no configuration and nothing to get wrong. The hardest to find and the best to own.
• Lower price, near-zero touch. Something so self-evident it generates almost no questions. Works only if acquisition is nearly free, because the customer count is large.
• Higher price, high touch. A consultancy with software attached. It can pay well. It is not a micro SaaS, and calling it one is how people end up with a job they cannot sell.

What this means for choosing an idea

Run both numbers before you write anything. They take a minute and they eliminate faster than any amount of thinking about the product:

1. Pick the income you actually need — not aspirational, the number that changes your life.
2. Pick a price you can defend to the buyer you have in mind.
3. Divide. If the customer count is larger than any audience you can plausibly reach, stop. The idea is not wrong, the price is.
4. Estimate support minutes honestly, including the customers who need ten times the average.
5. Multiply. If you land in heavy, the product needs to get simpler or the price needs to rise.

Most rejected ideas fail at step 3 or step 5, and both failures are visible before any code exists. That is the entire argument for doing this first.

What the arithmetic cannot tell you

It cannot tell you whether anyone wants the thing. Two numbers that close beautifully around an idea nobody needs are two beautiful numbers.

It also cannot tell you your support minutes — that estimate is a guess until you have customers, and first estimates are optimistic. Assume worse than you think, especially if the product touches money, data import, or anything a customer can misconfigure.

The arithmetic is a filter, not an answer. It removes the ideas whose shape cannot work for one person, quickly and for free, so the remaining question — does anybody want this — is the only one you have to spend real time on.

The short version

• Two numbers decide a micro SaaS: customers required by your price, and hours required by those customers.
• They pull against each other. Cheaper means more customers means more support.
• Under 2 hours a week is background; over 8 and support is the job.
• Both are computable before you build. Most bad ideas are visible at that point.
• Neither number tells you whether anyone wants it. That still costs a real test.