How to Validate a SaaS Idea Before Building

Why Most SaaS Ideas Fail Before Launch

The failure most founders fear is technical: "What if I can't build it?" But the more common failure is quieter and harder to detect: "What if nobody wants it?"

It happens all the time. A developer has an idea, gets excited, builds an MVP over a few weekends, launches on Product Hunt, and... silence. No signups, no feedback, no traction. The product works. The problem is that nobody was actively looking for a solution in the first place.

Validation is the antidote. It's the process of checking whether real demand exists for your idea before you invest serious time and energy into building. But validation is also one of the most skipped steps in indie hacking—because it feels slower than coding, because the methods aren't obvious, and because it's psychologically easier to build than to face the possibility that your idea might not have legs.

This guide walks through a practical approach to SaaS idea validation that doesn't require a marketing budget, an existing audience, or access to industry insiders.

What Validation Is Not

Before we get to what works, let's clear up what doesn't.

Asking friends and family Your friends want to be supportive. They'll say your idea sounds cool because they like you, not because they'd actually pay for it. This is the most common false positive in product validation.

Asking "would you use this?" Hypothetical questions produce hypothetical answers. Someone saying "yeah, I'd use that" in a conversation costs them nothing. Watching them pull out their credit card costs something. The gap between those two things is where most ideas die.

Building an MVP and "seeing what happens" Building first and validating after is the default for many developers—and the riskiest approach. By the time you launch, you've already invested weeks or months. Walking away feels like wasting that time, so you keep pushing even when the signals are weak.

Finding one Reddit thread that supports your idea Confirmation bias is real. If you go looking for evidence that your idea is good, you'll find it. One thread with a few supportive comments is not validation. It's a data point—and you need many more before you have a pattern.

Relying on "the market is big" logic "Project management is a $5 billion market" is not validation for your specific project management tool. Big markets have lots of well-funded incumbents. A big TAM means the problem is real. It doesn't mean there's room for your specific solution.

What Real Demand Signals Look Like

Real validation comes from observing what people already do and say in public, unprompted. Here's what to look for:

People are already looking for solutions The strongest demand signal is active search behavior. When you see people posting "Is there a tool that can [X]?" or "What's the best [Y] for [Z]?", they're telling you directly that a need exists and current solutions aren't meeting it.

People are complaining about existing tools When users consistently complain about the same features, pricing, complexity, or limitations of current tools, there's a gap. The more specific the complaint, the more actionable the signal.

People are building their own workarounds If people are describing a manual process involving multiple tools, spreadsheets, or duct-taped workflows, the problem is real enough that they've invested time in a partial solution. A product that consolidates that workflow into one tool has a clear value proposition.

People are paying for imperfect alternatives If users are paying for a tool that doesn't fully solve their problem—and complaining about it—they've demonstrated willingness to pay. The opportunity is to build something that solves the problem better.

The same pain point shows up in multiple places One Reddit thread is a data point. The same frustration showing up on Reddit, X, Hacker News, and in product reviews is a pattern. Multi-source signals are stronger than single-source signals.

Where to Find Demand Signals

You need evidence from places where people talk honestly and unprompted. Here are the most useful sources:

Reddit Search for subreddits related to your target market. Look for complaint threads, alternative-seeking posts, and "does anyone else hate..." discussions. Pay attention to the comments—that's where people elaborate.

X / Twitter Search for product names plus words like "frustrated," "alternative," "wish," "someone please build." The short format means people get straight to the point.

Hacker News Especially useful for developer tools and B2B SaaS. "Ask HN" threads asking for tool recommendations are gold. "Show HN" comment sections often contain honest, detailed feedback.

GitHub Issues If your idea relates to developer tools, open-source projects, or any product with a public repo, GitHub Issues contains detailed pain point descriptions, feature requests, and workaround explanations.

G2, Capterra, and app store reviews Read negative and middle-star reviews. Look for patterns in what users complain about. A single one-star review might be an outlier. Ten reviews mentioning the same missing feature is a signal.

How to Evaluate Signal Strength

Collecting signals is step one. Evaluating them is step two. Here's how to think about whether the evidence adds up:

Frequency: How often does this pain point come up? Across how many different threads, platforms, and users?

Intensity: How frustrated are people? Are they mildly annoyed or genuinely angry? Intensity correlates with willingness to switch and willingness to pay.

Recency: Are people still complaining about this? A pain point from three years ago might have been solved by now.

Alternatives: What are people using currently? Is there an obvious incumbent, or is the market fragmented? Fragmented markets with no clear leader can be easier to enter.

Switching behavior: Are people actively looking to switch, or just venting? "I hate this tool but I'll keep using it" is different from "I'm leaving as soon as I find something better."

If you're seeing frequency + intensity + active switching behavior across multiple sources, you have a meaningful demand signal. If you're seeing scattered, low-intensity complaints with no switching intent, the signal is weaker—and you should validate further before building.

When to Build, When to Validate Further

After gathering evidence, you'll typically land in one of three zones:

Strong signal: proceed to MVP You're seeing the same specific pain point across multiple sources, with high intensity and active alternative-seeking. Build a focused MVP that solves that specific pain point and get it in front of the users who were complaining.

Mixed signal: validate further There's some evidence but not enough to commit. Narrow your target user, focus on a more specific pain point, or run a lightweight test (landing page, waitlist, manual service version of your product) before building.

Weak signal: pivot or park The evidence isn't there. People aren't complaining about this problem, or they're complaining about something adjacent but not what you planned to build. This is actually a win—you saved yourself months of building the wrong thing.

FAQ

How much validation is enough? Enough that you're not relying on a single data point or source. If you can point to multiple threads, across multiple platforms, where real users are describing the same pain point and actively looking for solutions, you have enough to build a focused MVP.

What if I can't find any demand signals? That's information. It might mean the problem isn't as pressing as you thought, or you're looking in the wrong places, or people describe it differently than you expect. Before giving up, try broader search terms or different communities.

Should I validate before building an MVP or after? Before. An MVP is for testing whether your solution works, not for discovering whether the problem exists. Validate the problem first, then build an MVP to test your solution.

How long should validation take? A focused validation effort can be done in a few days to a week. The goal isn't to spend months researching—it's to gather enough evidence to make a confident decision, one way or the other.

Next Step

Ready to validate your SaaS idea with real demand signals?

Use SaaS Idea Validator →

Want to see the full validation workflow in action?

Read Validate a SaaS Idea guide →