How to validate a SaaS idea before you build it
Read what people already say in reviews and public threads, count the complaints that repeat, and look for signs they’d pay, before you write much code.
Short answer: the evidence already exists in public. Read a few hundred reviews of the tools your future customers use today, plus the threads where they complain. If the same problem keeps coming up, people describe workarounds, and some say they’d pay or switch, those are signs of demand worth testing with people who face the problem. If not, you saved yourself a month.
Where to read
| Source | What it tells you | What to watch for |
|---|---|---|
| Review sites: G2, Capterra, Trustpilot | What paying business customers dislike about current tools | Price complaints, missing features, “we switched because” |
| App Store and Google Play reviews | What everyday users hit in mobile apps | Repeated bugs, “bring back”, “I’d pay for” |
| Reddit threads | Honest workarounds and frustration, in their own words | Long replies, “how do you all handle”, tool recommendations |
| Comments on X, TikTok, Instagram and YouTube | How people talk about the problem casually | Phrases you can reuse on your landing page |
| GitHub issues | What developers ask maintainers to add | Reactions and “+1” on the same request across projects |
| Facebook groups and forums | Niche communities: trades, local businesses, hobbies | Questions asked again every few weeks |
What counts as a real signal
- 1
The same complaint, from different people
One angry review is noise. Twenty people describing the same problem in different words is a pattern. Keep a simple sheet: the complaint, where you saw it, and a short quote.
- 2
Workarounds
Spreadsheets, screenshots pasted into email, three tools glued together. Ask why they chose the workaround and whether changing it is worth the effort.
- 3
Money and urgency
Look for “I’d pay for”, “we’re switching”, “cancelled because”, and words like client, deadline or lost sales. Ask how often the problem occurs, who owns the budget and whether they have paid to solve it before.
- 4
People who already pay for something
Complaints from paying customers of an existing tool are the best sign of all. They’ve proven they spend money on this job and they’re telling you what’s missing.
Turn it into a decision
After a few hours you should be able to fill in three lines. Who has the problem. What they call it, in their own words. What they use today and what they hate about it. If you can’t, keep reading or pick a different problem. If you can, those three lines become your waitlist page.
Questions
How many reviews should I read?
Enough that new reviews stop surprising you. For most niches that’s a few hundred across three or four competitors, which is a day of reading.
What if there are no competitors?
Then look for the workaround people use instead, and check whether anyone is paying for it. Check how people currently solve the problem, including manual work, before treating the absence of direct competitors as demand.
Can I use AI to read the reviews?
Yes, to group and count them. Still read a sample yourself: the exact words people use are what makes a landing page work.