It is a sequencing failure, and I made it myself.
The mechanism is boring: the build is the only part of a SaaS idea I can estimate accurately, because I have shipped before. Everything else — whether anyone is looking for this, whether they will pay, what happens when dozens of them need something — is a guess I dress up as an estimate. So my reasoning pools where my confidence is, and the hand-waved parts turn out to be the ones that decide it.
So I reordered. Now I judge an idea on the parts I am worst at estimating, first, and the ordering has done more for me than any individual insight inside it.
The four places they actually die, in the order they bite: distribution, pricing power, support load, platform dependence. Distribution kills more than the other three combined, and it is the one I deferred longest every single time.
The rule that makes the order pay: it takes an afternoon to establish that a problem is real and documented. It takes months to discover you cannot reach the buyer. Do the afternoon first.
The one I had to be honest with myself about: if you pick an idea and then research it, you will find support. Not because you are dishonest — search rewards the query you typed, and you typed the one that matches your idea. Reading a market first and letting candidates fall out of it is the only version of this I trust now.
Our own run went that way: 56 documented problems from 41 sources across 20 sub-markets, 24 pages read in full, 32 with a link you can open and the rest labelled as our estimate rather than quietly promoted.
The other thing I did not expect: the ideas that clear this bar are boring. They feel obvious. The reason nobody took them is usually distribution rather than difficulty — solvable if you know it going in, fatal if you find out in month seven: https://whittleos.com/guides/saas-ideas