The premise: micro SaaS is not small SaaS. It is a business shaped so one person can run it indefinitely, and that shape is decided by two numbers that pull in opposite directions. Get the first wrong and you never reach the income; get the second wrong and you reach it and then cannot keep it.
Number one is division, not strategy. At a flat monthly price the customer count your target income needs is fixed the moment you pick the price. 29 a month against a 3000 a month target is 104 customers — every month, net of churn, forever.
What that number does downstream is the interesting part. It sets the acquisition problem, because 104 paying customers is a real audience you have to reach repeatedly since some leave every month. It sets churn tolerance. And it is the cheapest lever you have: doubling the price halves the count, and nothing else in the business moves it that far. That is why pricing power is not a detail.
Number two is the one that gets skipped. Every customer consumes support time — questions, edge cases, billing, the bug only they hit. At 15 minutes per customer per month, 104 customers is 26 hours a month, about 6 a week, before you write a line of code.
The bands are not arbitrary; they come from what a solo week can absorb. Under 2 hours a week is background noise and the business runs while you build. 2 to 8 is a real share of your build time — survivable, and the difference between shipping monthly and shipping quarterly. Over 8 and support is the job, which is where a product quietly turns into a service business you did not choose.
Why the two fight, which is the actual content of 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. Each obvious move trades one constraint for the other.
So the combinations that work are narrower than they look. Higher price and low touch: one expensive well-defined problem, no configuration, nothing to get wrong — hardest to find, best to own. Lower price and near-zero touch: something so self-evident it generates almost no questions, which only works if acquisition is nearly free. Higher price and high touch is a consultancy with software attached; it can pay well, and calling it a micro SaaS is how people end up with a job they cannot sell.
Now the implementation detail, which is why this belongs on dev.to rather than anywhere else. Our worked example originally used a larger minutes-per-customer figure, computing to a hair under 8 hours a week. The band comparison ran on the unrounded value, so the classification was correct — but the page DISPLAYED 8, immediately beside a band list reading over 8 hours a week is heavy.
The arithmetic was right and the page was still wrong. A reader sees a number labelled moderate sitting next to a rule saying that number is heavy, and reasonably concludes one of them is broken. The defect was that a worked example sat on a boundary its own rounding straddled — and it existed only in rendered output, not in any value the code compares. Which is the general lesson: display rounding is a semantic boundary, and reading the built page catches what reading the source cannot.
Both calculators are on the site so you can run them against your own numbers rather than mine: https://whittleos.com/guides/micro-saas-ideas
Top comments (0)