Micro SaaS ideas, each tied to a recorded problem and its source

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 pulling in opposite directions: how many customers your price requires, and how many hours those customers cost you.

Below are 13 directions, one per market in the problems our sweeps have recorded, each tied to a recorded problem and the page it came from. Then both numbers, run on 8 real ideas from one market rather than argued about: get the first wrong and you never reach the income; get the second wrong and you reach it and cannot keep it.

Micro SaaS directions, one per market

We have recorded 1,823 problems from public sources. The problems pages group them into 13 markets; a problem can sit in more than one, and 220 fit none. For each market we took one theme that keeps coming back and is narrow enough to build a single product on, counted how many of the market's recorded problems carried it on 2026-09-29, and wrote down the micro SaaS it points at. The counts and the recorded problems are data. The directions are ours.

The review requests and the revenue view live inside someone else's platform — Shopify and WooCommerce. Depending on one platform is the one deal-breaker our checks mark down rather than rule out, so neither is disqualified, but each carries that risk into every later step.

To see everything recorded for one market, open its problems page, or type your own niche into Pain Receipts — free, no signup. To have a market searched for you instead, a Discovery run reads live sources and comes back with up to 5 ideas, each with the problem behind it, from 2 credits. A published run shows what that looks like before you pay for one.

Micro SaaS ideas for developers

If you can build any of these yourself, the constraint is rarely the code. It is how fast you can find out whether anyone pays — ideas ranked by how fast a developer reaches evidence sorts the same space by what it costs to find out, not by what it could earn.

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.

Three things fall out of it immediately, and none of them is about the product:

• It sets your acquisition problem. The count is a real audience you have to reach repeatedly, because some of them leave every month.
• It sets your churn tolerance. At 5 per cent monthly churn you are replacing a slice of that count every month before you grow at all.
• It is the cheapest lever you have. Doubling the price halves the 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 support time — questions, edge cases, billing, the bug only they hit. Call it minutes per customer per month and it multiplies by the count you just derived.

The bands that matter for one person are not arbitrary. They come from what a solo week can absorb: under 2 hours a week is background noise; up to 8 a real share of your build time is now support; past 8, support is the job, and the product has quietly become a service business you did not choose. Those two boundaries are imported here from the same constant the support calculator switches on, so this page cannot quote a threshold the tool does not use.

The squeeze, run on an idea we actually held

Here is the part the argument was missing. One of the 8 cards in our idea library is a pure pricing play — Lean Invoice (cheaper, no-frills), aimed at solo freelancers on a tight budget, from a sweep on 2026-06-03. Our own engine did not clear it. It came back HOLD at 51.

Sweep a price ladder against it at $3,000 a month and 15 support-minutes per customer, and the reason shows up without needing an opinion:

The arithmetic rules out the bottom 2 rungs before a line of code exists. At $9 the support alone is 19.2 hours a week; even at $19 it is 9.1. Both are past the line where support is the job. The cheapest rung that survives is $29, and the first genuinely comfortable one is $99 — where the whole business is 31 customers and under 2 hours a week.

Which is the difficulty with a cheap-and-no-frills product, stated as arithmetic rather than as advice: the thing that makes it attractive to the buyer is the thing that makes it unrunnable by one person. Worth knowing that the pricing analysis reached the same boundary from the other direction — a threshold written into a prompt as a judgement, landing on the same rungs this table rules out on hours. Two derivations, neither told about the other.

The three shapes that survive it

Lowering the price raises the count, which raises total 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 obvious moves each trade one constraint for the other, and what is left is narrower than it looks:

• Higher price, low touch. 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. So self-evident it generates almost no questions. Works only if acquisition is nearly free, because the 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 the ideas on one market actually looked like

The arithmetic filters shapes. It does not pick between ideas that pass it. To show what that second step does, here is the whole library: 8 ideas in time-tracking & invoicing for freelancers, from two consecutive sweeps, sorted the way anyone would sort them — best number first.

An idea generator would have cheered for all 8. What came back was 4 validate, 2 hold, 2 kill — on one market, in two days.

The same score, the opposite decision

Look at the middle of that table.

That is not a rounding artefact and it is not a bug. A weighted score says how good an idea looks across seven areas. The verdict is decided by checks that can fail outright — no documented problem behind it, a dependency with no exit, a support shape one person cannot carry — and a filter failing does not care how well the rest scored.

So the useful reading of the table is not top-down. It is: the number tells you how promising, and something else entirely tells you whether it is allowed. A tool that only gives you the number has handed you the half that cannot say no. Ours publishes both, and the weights behind the number as well, which is an invitation to tell us they are wrong.

What stopped the four that did not clear

The reasons are the part a page like this normally leaves out, and they are the only part a competitor with no citations cannot produce. Verbatim from the cards:

Two patterns, and both are more useful than a score. The held pair failed on the same thing: nobody had paid yet, and a price test is cheap, so holding is the correct verb. The killed pair failed on the wedge — replicable by a spreadsheet, or generic enough that nothing distinguishes it. That is not a problem more evidence fixes.

And notice what the second held card says about itself: competing on price compresses margins. That is the same conclusion the table above reaches in hours, arrived at in words by a different part of the system. Two independent readings of one idea, agreeing — which is worth exactly as much as it sounds and no more, because both halves are ours.

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.

And it cannot be re-derived from this page onto your own idea by reading. Take your price to the customers-needed calculator, take the answer to the support-hours one, and read the band that comes back.

The short version

• 13 directions, one per market, each tied to a recorded problem and the page it came from. The directions are ours to propose and yours to check.
• Two numbers decide a micro SaaS: customers required by your price, hours required by those customers. They pull against each other.
• On a real held idea at $3,000 a month, the bottom 2 price rungs are ruled out on support hours alone — the cheap end is where a one-person product stops being one.
• The comfortable rung is $99 and 31 customers. Cheaper is not safer.
• 8 ideas in one market came back 4 validate, 2 hold, 2 kill. Sorting by score does not reproduce the verdicts.
• Two of them share a score and disagree on the decision. The number says how promising; the checks say whether it is allowed.