The graveyard of failed SaaS products is full of technically excellent software that solved problems nobody had. Validation is the difference between building something people pay for and building something people politely say "looks cool" about.
Here is a step-by-step process that takes less than a week and costs nothing.
Step 1: Check Existing Demand Signals
Before you brainstorm in a vacuum, find out if people are already asking for what you want to build. The three best sources:
- Hacker News — Search for your problem keyword. Look at "Ask HN" threads. If multiple people describe the same pain point independently, that's a real signal.
- Reddit — Check r/SaaS, r/microsaas, r/indiehackers, r/Entrepreneur, and niche subreddits for your target audience. Search for complaints, not solutions.
- GitHub Issues — If open-source tools exist in your space, read the issues. Feature requests with 10+ thumbs-up are validated demand.
Shortcut: Our directory tracks 500+ SaaS ideas extracted from these exact sources. Each idea includes mention counts so you can see how much demand exists. Browse the full directory →
The mention count matters. An idea mentioned 3 times is a maybe. An idea mentioned 30+ times across different communities is a pattern.
Step 2: Talk to 5 Real People
Online signals tell you a problem exists. Conversations tell you if it's painful enough to pay for.
Find 5 people who have the problem. The best places to find them:
- Reddit threads where they complained about it
- Twitter/X posts describing the workflow
- Slack and Discord communities for your target niche
The 3 questions to ask:
1. How do you handle this today? — Their current solution reveals the real workflow. If they say "I use a spreadsheet," you're onto something. If they say "our existing tool handles it fine," move on. 2. What's the most annoying part? — Vague answers ("it's kind of slow") mean mild annoyance. Specific answers ("I spend 45 minutes every Monday re-entering data from our CRM into our invoicing tool") mean real pain. 3. What would you pay to make this go away? — Don't ask "would you pay?" (everyone says yes). Ask "what's the most you'd pay per month?" The number reveals willingness.
Validation threshold: If 4 out of 5 people describe a similar painful workflow and name a price above $10/month, you have a validated problem.
Step 3: Check the Competitive Landscape
Competition is good — it proves the market exists. No competition usually means no market.
What to check:
| Signal | What It Means |
|---|---|
| 0 competitors | Either too niche or no real demand. Proceed with caution. |
| 1-3 competitors | Healthy. Room for differentiation. |
| 10+ competitors | Crowded. You need a very specific angle (cheaper, simpler, niche-specific). |
| 1 dominant player with vocal complaints | Best case. Build the version their unhappy users want. |
Search for competitors on Google, Product Hunt, G2, and Capterra. Read the 1-star reviews of existing tools. Those reviews are your feature roadmap.
Step 4: Validate Willingness to Pay
Talking is cheap. Paying is real. Before you write code, test if people will actually open their wallets.
Option A: Landing page test Build a single page describing the solution. Include a clear CTA — "Join the waitlist" or "Pre-order for $X/month." Drive traffic from the communities where you found the demand signals.
- 5%+ signup rate from cold traffic = strong interest
- 2-5% signup rate = decent, refine your positioning
- Under 2% = your messaging or your idea needs work
Option B: Manual service first Offer to solve the problem by hand for 3-5 people. Charge a discounted rate. If they pay you to do it manually, they'll pay for software that automates it. This also teaches you the workflow better than any amount of research.
Option C: Pre-sell lifetime deals Offer 20 lifetime licenses at $49 each. If you sell 10+, you have $500+ in revenue and 10 committed beta testers before writing a line of code.
Step 5: Scope Your MVP
Validation doesn't mean building the full product. It means building the smallest thing that solves the core pain.
- One user type (not "teams and individuals")
- One core workflow (not "project management" — pick "task assignment for small teams")
- One pricing tier (don't build free. Charge from day one.)
- Two-week build target (if it takes longer, cut scope)
Step 6: Use Trending Data to Cross-Check
Your personal validation is one data point. Cross-reference it with broader signals.
- Mention count — how many times the problem or solution was discussed across Hacker News, Reddit, and GitHub
- Category — which market segment the idea fits into
- Difficulty — whether it's buildable in a weekend or requires months of work
If your idea matches a high-mention, easy-difficulty entry in the directory, your conviction should go up. If it doesn't appear at all, that's a flag worth investigating.
Search for your idea in the directory →
The Validation Checklist
Before writing code, you should have:
- [ ] 10+ independent mentions of the problem online
- [ ] 5 conversations with people who have the problem
- [ ] 3+ people willing to name a price above $10/month
- [ ] Competitive landscape mapped (who exists, what they miss)
- [ ] Landing page or pre-sale with measurable conversion
- [ ] MVP scoped to a 2-week build
Check all six and build with confidence. Miss two or more and keep validating.
Start With Validated Ideas
Skip the research phase entirely. Our directory has 500+ ideas already validated by community demand signals — sorted by category, difficulty, and mention volume.
Browse all ideas → | Filter by easy difficulty → | See trending ideas →