Most developers build SaaS products the same way:
guess a problem, build for weeks, launch… and hear nothing.
I’ve been there.
Here’s a validation approach that actually works—using real conversations from Reddit and GitHub, before you write a single line of code.
Most developers I know have the same problem: we're great at building things, but terrible at knowing if anyone actually wants them.
You spend weeks (or months) building a SaaS product, launch it, and then... crickets. No signups. No paying customers. Just you, your code, and the crushing realization that you built something nobody needed.
But here's the thing: your potential customers are already telling you what they want. They're just doing it on Reddit, GitHub, Stack Overflow, and other platforms where developers hang out.
The Problem with Traditional Validation
Most validation advice is either too theoretical or too expensive:
- Surveys? Low response rates, and people lie about what they'd pay for.
- Landing pages? You're still guessing what problem to solve.
- Focus groups? Expensive and often biased.
- "Build it and they will come"? We all know how that ends.
But there's a better way: listen to real conversations happening right now.
Why Reddit and GitHub Are Goldmines for Validation
Reddit and GitHub aren't just platforms—they're real-time market research tools where people discuss problems, ask for solutions, and complain about what's missing.
Reddit: Where Problems Live
Reddit is where people go to vent, ask questions, and look for solutions. It's unfiltered, honest, and full of people actively describing their pain points.
What to look for:
- Posts asking "Is there a tool that does X?"
- Complaints about existing solutions
- Questions about workflows or processes
- Discussions about alternatives to current tools
Example: I recently saw a thread on r/SaaS where someone said:
"I'm tired of manually tracking my customer feedback in spreadsheets. There has to be a better way, but I can't find a simple tool that doesn't cost $50/month."
That's not just a complaint—that's a validated problem with clear requirements (simple, affordable, solves spreadsheet pain).
GitHub: Where Developers Show Their Pain
GitHub issues, discussions, and README files reveal what developers actually need. When someone opens an issue saying "I wish this tool had X," that's validation.
What to look for:
- Feature requests in popular repos
- Issues describing workarounds for missing features
- Discussions about tool limitations
- README files asking for alternatives
Example: A popular open-source project had 200+ upvotes on an issue requesting:
"Can we get a simple API to export data? The current method requires 10 steps and doesn't work for automation."
If 200 developers want this, there's probably a market for a tool that does it better.
The 3-Step Validation Framework
Here's a practical framework I use to validate SaaS ideas using these platforms:
Step 1: Find the Problem (Not the Solution)
Start with a problem, not a product idea. Search for:
- Pain point keywords: "frustrated with", "tired of", "wish there was"
- Workflow problems: "how do I", "is there a way to", "looking for a tool"
- Complaints about alternatives: "[competitor] is too expensive", "[tool] doesn't work for"
Example search queries:
"frustrated with invoice management"
"looking for a simple CRM"
"tired of using spreadsheets for [task]"
Step 2: Measure the Signal
Not every complaint is a business opportunity. Look for:
- Volume: How many people are discussing this?
- Recency: Is this an ongoing problem or a one-time complaint?
- Emotion: Are people frustrated, desperate, or just curious?
- Willingness to pay: Are they using paid alternatives or free workarounds?
Red flags (skip these):
- One-off complaints with no engagement
- Problems that are too niche (5 people total)
- Issues that are already solved well by existing tools
- Complaints about free tools (hard to monetize)
Green flags (build these):
- Multiple threads with 50+ upvotes
- Active discussions with 20+ comments
- People asking "does this exist?" repeatedly
- Complaints about expensive tools (price sensitivity = opportunity)
Step 3: Engage Before Building
This is the most important step: talk to people before you code.
What to do:
- Find 5-10 people discussing the problem
- Comment genuinely (don't pitch yet)
- Ask follow-up questions: "What would an ideal solution look like?"
- Offer to build it if there's interest
- Get 3-5 people to commit to trying it when ready
Example engagement:
"I've been thinking about this problem too. If I built a simple tool that did [specific thing], would you use it? What features would be must-haves vs. nice-to-haves?"
If you can't get 5 people to say "yes, I'd try that," don't build it yet.
Real Example: How I Validated a Tool Idea
I was considering building a tool to help founders find their first customers by searching social conversations. Instead of guessing, I searched Reddit for:
- "how to find first customers"
- "where do startups find early users"
- "customer discovery tools"
I found:
- 47 Reddit threads discussing this problem
- 12 GitHub repos trying to solve parts of it
- 8 Hacker News posts asking for better solutions
- Multiple complaints about existing tools being too expensive or too complex
Then I engaged. I commented on 10 threads, asked questions, and got 23 people to say they'd try a simpler solution.
That's when I knew: There's real demand here. So I built it.
(That experiment eventually turned into a small tool I use to track these conversations. The process itself is what matters.)
Tools That Make This Easier
Manually searching Reddit and GitHub works, but it's slow. Here are tools that help:
For Reddit:
- Reddit's native search (basic but works)
- Tools that aggregate discussions across subreddits
- Social listening platforms that track conversations
For GitHub:
- GitHub's search and trending repos
- Tools that monitor issues and discussions
- Platforms that track developer pain points
Pro tip: Use a tool that searches multiple platforms at once. I built Needle specifically for this—it searches Reddit, GitHub, Hacker News, Stack Overflow, and more simultaneously, so you can validate ideas faster.
Common Mistakes to Avoid
Mistake 1: Confirmation bias
You want your idea to work, so you only look for positive signals. Force yourself to look for reasons it won't work too.
Mistake 2: Building too early
Getting 2 people interested isn't validation. Wait until you have 10+ people actively asking for it.
Mistake 3: Ignoring competitors
If 5 great tools already solve this, maybe don't build another one. Look for gaps instead.
Mistake 4: Not talking to people
Reading threads isn't enough. You need to engage, ask questions, and get commitments.
The Validation Checklist
Before writing code, make sure you can answer:
- [ ] Can I find 20+ people actively discussing this problem?
- [ ] Are they frustrated enough to try a new solution?
- [ ] Do they mention what's missing from current tools?
- [ ] Can I get 5+ people to commit to trying my solution?
- [ ] Is there a clear gap in the market (not just "I can do it better")?
If you can't check all boxes, keep validating. It's cheaper to pivot an idea than to build the wrong product.
Final Thoughts
Validation isn't about surveys or landing pages. It's about listening to real people discuss real problems in real time.
Reddit and GitHub are free, unfiltered, and full of people telling you exactly what they need. The question is: are you listening?
Next steps:
- Pick a problem you're considering solving
- Search Reddit and GitHub for discussions about it
- Measure the signal (volume, emotion, willingness to pay)
- Engage with 5-10 people discussing it
- Only build if you get real commitments
Remember: It's better to validate for a month than to build for 6 months and find out nobody wants it.
Top comments (0)