The 12 Rules for Bulletproof SaaS Validation

Every founder says they "validated" their idea. Almost none of them mean the same thing by it. This is the numbered rule-book we hold ourselves to before a single line of production code gets written — twelve non-negotiable checks that separate a real, fundable business from a side project you merely enjoyed building.

In summary, the key framework for mastering SaaS validation relies on requiring evidence of payment before evidence of interest, and on setting your pass/fail threshold before the sprint starts, not after.

1. Validate the complaint, not the idea. Look for a recurring problem statement in other people's own words before you invent a solution to fit it.
2. Require a form of payment before a form of feedback. A completed pre-order or deposit is data; a "yes, I'd use that" is not.
3. Set your pass/fail threshold before you start. Decide what counts as validated — 10 pre-orders, 5 pilot calls — so you can't rationalize a weak result after the fact.
4. Cap the sprint at 48 hours. An open-ended validation phase always expands to fill however much time you give it.
5. Talk to the person who complained, not a random sample. The person who posted the original pain point is a far higher-intent lead than a stranger you cold-message.
6. Log every "no" with a reason. A rejection with a reason attached is more useful data than a vague "maybe later."
7. Build the landing page before the product. If you can't get someone to click a waitlist button, they definitely won't pay for the finished thing.
8. Treat a free trial as an unproven hypothesis. Willingness to try something for free tells you almost nothing about willingness to pay for it.
9. Cross-check the pain point in at least two unrelated communities. A complaint that only exists in one subreddit might be a local quirk, not a market.
10. Distrust your own enthusiasm. The idea you personally find exciting is the one you're most likely to over-validate.
11. Measure reply depth, not just reply count. Ten one-word replies mean less than two detailed, specific responses about the exact problem.
12. Kill the idea in writing if it fails. Write down the outcome and move on — a half-killed idea has a way of quietly consuming another three months.

Your next step

Pick a pain point you've already seen repeated across independent threads, write down your pass/fail threshold, and start the 48-hour clock. The rules above aren't a checklist to feel good about — they're a filter designed to kill weak ideas fast so you only spend real build time on the ones that survive it.