SaaS ideas: where they actually die

All guides

Ask a room of technical founders why their last SaaS idea failed and almost nobody says "I could not build it". They say they built it and nobody came, or people came and would not pay, or people paid and then needed so much help that the business became a job.

None of those are product problems. That is the useful thing to know before choosing the next one.

The product is the part you are best at, which is why it misleads you

If you can ship software, the build is the part of a SaaS idea you can estimate accurately. Everything else — whether anyone is looking for this, whether they will pay, what happens when a hundred of them need something — is a guess dressed up as optimism.

So the evaluation tilts. You spend your reasoning where you are confident and hand-wave where you are not, and the hand-waved parts are exactly the ones that decide the outcome.

The corrective is unglamorous: judge an idea on the parts you are worst at estimating, first.

Where they actually die

Distribution. Not "marketing" as a category, but a specific, repeatable way to reach the buyer that you can do without an audience. If the honest answer is "post about it and hope", the idea has no distribution, and no amount of product quality substitutes. This kills more SaaS ideas than everything else combined, and it is the one founders defer thinking about longest.

Pricing power. Whether the problem is worth enough to the buyer to support a price that makes the business worth one person's time. A real problem that is worth $5 a month to its sufferer is a real problem you cannot build a business on alone.

Support load. What happens at scale, where "scale" for a solo founder means dozens of customers, not thousands. A product that needs a conversation per customer is a consultancy with a login screen.

Platform dependence. Whether the business survives the platform it sits on changing its rules. Building on one API is building on somebody else's roadmap.

The questions, in the order that saves time

These are the checks a candidate is run through here, and the ordering matters more than the list:

• Is there a real, documented problem behind it?
• Is there a path to money that repeats?
• Is there a repeatable way to reach the buyer?
• Can it charge enough to be worth one person's time?
• Can it run without hand-holding every customer?
• Does it survive if one platform changes its rules?
• Is there a product left if an AI vendor ships this feature?
• Can you, specifically, sell and operate it?
• Can it launch without licences or compliance audits?
• Can it sell without legal review and a sales team?

Answer them in that order and the cheap ones eliminate before the expensive ones. It takes an afternoon to establish that a problem is real and documented; it takes months to discover that you cannot reach the buyer. Doing the afternoon's work first is most of the value.

Notice that "is this technically interesting" does not appear. Not because it does not matter to you — it does, and a business you find boring is one you abandon — but because it is not a survival constraint, and mixing preferences into a filter is how a filter stops filtering.

Evidence before conviction, not after

The order in which you gather evidence determines what you conclude.

If you pick an idea and then research it, you will find support. Not because you are dishonest — because search rewards the query you typed, and you typed the one that matches your idea. If instead you read what a market complains about and let candidates fall out of it, the evidence arrives before you have anything to defend.

Our own published run works that way: 56 documented problems pulled from 41 sources across 20 sub-markets, with 24 pages read in full. Of those problems 32 carry a link you can open; the rest are labelled as our estimate. The distinction is the point — a problem without a source is a hypothesis, and filing it as evidence is how a research process quietly becomes a confirmation process.

What a surviving idea looks like

Not exciting. A specific, documented, recurring problem, owned by a buyer you can name and reach without an audience, who already pays for something adjacent, in a market where the work does not require you to be available.

Ideas that clear that bar rarely feel like insights. They feel obvious, and slightly boring, and the reason nobody has taken them is usually distribution rather than difficulty — which is a solvable problem if you know that going in, and a fatal one if you discover it in month seven.

If the idea is meant to be run by one person, there is a second layer of arithmetic on top of all this: how many customers your price actually requires, and how many hours those customers cost you. Those two numbers pull against each other, and they are the subject of the companion guide on micro SaaS ideas.

The short version

• SaaS ideas rarely die of the product. They die of distribution, pricing power and support load.
• You estimate the build accurately and everything else optimistically, so judge the everything else first.
• Order the checks cheapest-to-establish first; an afternoon of reading beats months of building.
• Gather evidence before you choose, or you will gather confirmation after.
• A surviving idea usually looks boring. That is not a warning sign.