Open on the observation, because this audience has lived it: ask technical founders why the last SaaS idea failed and almost nobody says they 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.
The bias that produces that, stated as an estimation problem: the build is the only part you can estimate accurately, because you have done it before. Everything else is a guess wearing the clothes of an estimate. So reasoning pools where confidence is highest and the hand-waved parts are precisely 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, in four places. Distribution — not marketing as a category but a specific repeatable way to reach the buyer without an audience; if the honest answer is post about it and hope, there is no distribution and product quality does not substitute. This one kills more than the rest combined and is the one founders defer 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 worth a couple of dollars a month to its sufferer is a real problem you cannot build a solo business on.
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 ordering is worth more than the list, and this is the part to steal: answer cheapest-to-establish first. It takes an afternoon to establish that a problem is real and documented. It takes months to discover you cannot reach the buyer. Doing the afternoon first is most of the value, and it is free.
What is deliberately NOT in the filter: is this technically interesting. It matters to you, and a business you find boring is one you abandon — but it is not a survival constraint, and mixing preferences into a filter is how a filter stops filtering.
The evidence-order failure mode, which is the one an engineer will recognise as a bug: if you pick an idea and then research it, you will find support. Not through dishonesty — search rewards the query you typed, and you typed the one matching your idea. Read what a market complains about first and let candidates fall out of it.
Our own run works that way and the numbers are the point rather than the boast: 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.
That distinction is the whole discipline. A problem without a source is a hypothesis, and filing it as evidence is how a research process quietly becomes a confirmation process.
The four checks in the order that saves time: https://whittleos.com/guides/saas-ideas
Top comments (0)