How to validate a SaaS idea before you build it

Step 1 — Find pain where nobody was trying to help you

Real validation for a SaaS idea means finding evidence of the underlying pain in places where your future customers were already complaining before you showed up. Reddit threads where someone asked “is there a tool that does X” and got forty upvotes and no good answer. Hacker News comments about failing to find a solution. App Store reviews complaining about the incumbent you plan to compete with. That kind of signal is honest because nobody was trying to help you when they wrote it.

The absence of this signal matters as much as its presence. If you search for your pain across Reddit and HN and find almost nothing (not even vague frustration), that's a real finding. It means either the market is not expressing this pain publicly, the problem is not causing enough frustration to generate discussion, or you are describing it in language your customers don't use. All three are worth understanding before you build.

When you do find the threads, pay attention to the language. The words real people use to describe their problem are rarely the words founders use to describe their solution. “Async project updates” in your pitch deck might correspond to “too many status meetings” and “nobody reads the updates I send” in the posts. That gap matters for positioning, messaging, and where you find your first customers.

Step 2 — Separate pain from willingness to pay

Pain that people complain about publicly is not always pain they will pay to solve. Look for the posts where someone mentions what they tried, what it cost, or what they would pay. A single specific “I'd pay $50/month for this” in a thread is worth more than twenty “great idea!” replies.

Willingness-to-pay signals appear in a few forms. Explicit: someone states a price. Behavioral: someone describes paying for an inferior solution because nothing better existed. Comparative: someone describes the cost of the current workaround in time or money. All three are real signals. The absence of all three (pain with no evidence of anyone trying to pay their way out of it) is a warning worth taking seriously.

Be particularly cautious with problems people describe as annoying rather than costly. Annoying problems generate complaints. Costly problems generate budgets. The distinction between “this wastes an hour a week” and “this cost us a client” is the difference between a nice-to-have and a painkiller.

Step 3 — Map who already tried to solve this

Competitors are not a reason to stop. They're evidence that the pain is real and that someone will pay to solve it. The validation question when competitors exist shifts from “does this market exist?” to “what are they getting wrong?”

The most useful competitive intelligence for a pre-build founder is not their pricing page or their feature list. It's their App Store reviews. When users take time to write a review, they're describing what they needed that they didn't get: missing integrations, onboarding friction, pricing resentment, support failures. That's your feature roadmap and your positioning argument in one source.

Map the tools, workarounds, and manual processes people mention when they describe living with the pain. The workarounds are especially revealing. If people are solving a $200/month problem with a combination of spreadsheets and Zapier, they've already decided the pain is worth solving. They just haven't found the right tool yet.

Step 4 — Define your persona from evidence, not assumptions

Most founders build an ideal customer profile before they have any customers. The result is a persona shaped by who they imagine buying, not who the evidence shows is already expressing the pain. These two are often meaningfully different.

Build your target persona from the signals in the posts: the job titles that appear, the tools people say they use alongside the one they wish existed, the frequency with which the pain shows up in their workflow, and the language they use to describe urgency. A persona built this way is specific and falsifiable. You can test it against what you find when you talk to real people, and it will tell you when you're talking to the wrong segment.

Step 5 — Build a verdict before you build a product

Validation ends with a decision, not a report. After you've collected the evidence, you should be able to state clearly: this pain is real, this many people express it publicly, they have tried these alternatives and found them lacking, they signal willingness to pay at this range, and the specific gap I am filling is this. If you can't state all of that from specific evidence, you haven't finished validating.

The verdict is binary: build or do not build. “Maybe if I add this feature” and “probably once the market matures” are not verdicts. They're ways of avoiding the decision the evidence is already pointing you toward.

How Proven runs this process for you

Proven automates the evidence-gathering steps above. You describe your SaaS idea, we fetch live signals from Reddit, HN, and App Store reviews, and return a Founder's Brief with pain evidence, competitor map, target persona, pricing signals, and a verdict. Four minutes. One-time cost per idea. No subscription.

The brief doesn't replace steps 4 and 5. Interpreting the evidence and making a decision still requires your judgment. But it replaces two to three days of manual searching with four minutes of structured evidence, and it surfaces things a manual search would miss: the competitor threads you didn't find, the subreddits you didn't know to check, the Pain Score that tells you whether the signal is strong enough to act on.

If you want to go through the full checklist of what good validation covers, see the SaaS validation checklist.

Frequently asked questions