How to Validate a SaaS Idea Before Building It

The most common mistake in SaaS is building a product for six months and then discovering that the problem you solved isn't painful enough for people to pay to solve it. Validation doesn't eliminate this risk entirely, but it compresses the feedback loop from months to weeks and costs almost nothing to do.

Here's how to validate a SaaS idea with enough confidence to start building — without wasting time on fake validation that only confirms your own assumptions.

Quick answer: Real validation requires evidence that someone will pay — not compliments or waitlist signups. Start with 5 discovery interviews about the problem (not the solution), then build a landing page and drive 200-500 targeted visitors. Set a clear threshold before you start: 5 pre-orders or 3 paying concierge customers. The full validation cycle takes 3-4 weeks and costs almost nothing.

What validation actually means

Validation has one job: produce evidence that someone other than you would pay for this product. Not evidence that they "find it interesting" or "would use it if it were free" — evidence that the problem is painful enough and the solution compelling enough that money changes hands.

The bar is deliberately high. Anything short of that standard can lead you to build something people politely encouraged without actually wanting.

Step 1: Write the problem statement, not the solution

Before you do anything else, write one sentence:

"[Specific person] struggles with [specific problem] when they [specific context], which costs them [specific consequence]."

Example: "B2B SaaS founders struggle to track which support tickets indicate upcoming churn when they have more than 100 active customers, which costs them $2-5K MRR monthly in undetected churn."

If you can't write this sentence concretely, you don't have a clear enough problem to validate. The more specific the sentence, the more targeted your validation will be.

Step 2: Find 5 people who have this problem

Before building anything, have 5 conversations with people who match your specific person description and are experiencing your specific problem.

Where to find them:

LinkedIn search for job titles + industries matching your ICP
Twitter/X communities where your ICP hangs out
Reddit communities for your target domain (r/entrepreneur, r/SaaS, r/webdev, category-specific subs)
Indie Hackers, Slack communities, Discord servers
Your existing network — who do you know in this space?

How to ask for a conversation:

Don't ask for feedback on your idea. Ask about their problem:

"I'm researching how [type of person] handles [specific problem]. I'm not selling anything — I want to understand what's painful about the current approach. Would you have 20 minutes to share how you currently handle this?"

This removes the social pressure to be nice about your idea. You want honest problem description, not polite feedback.

Step 3: Run discovery interviews (not pitch sessions)

The goal of each conversation is to understand the problem from their perspective, not to validate your solution.

Questions that work:

"Walk me through the last time you dealt with this problem. What happened?"
"How are you handling this today?"
"What's the most frustrating part of how you handle it?"
"Have you looked for solutions? What did you try? Why didn't it stick?"
"What would it mean for you if this problem went away?"

Questions to avoid:

"What do you think of this idea?" (social pressure to be nice)
"Would you use this if we built it?" (hypothetical, unreliable)
"What features would you want?" (premature, anchors you to their suggestions)

After 5 conversations, you should have a clear sense of: Is this problem real? Is it painful enough? Are they actively seeking solutions? If yes across all three, proceed.

Step 4: Build the smallest possible proof of the problem

Before any code, test whether people will take a meaningful action to solve this problem.

Options, in order of increasing effort:

Landing page + waitlist. Build a one-page site (Carrd, Framer) explaining the problem and the solution in broad strokes. Add an email waitlist. Drive 200-500 targeted visitors via Twitter/LinkedIn posts, community posts, or direct outreach. If 10%+ sign up, that's signal.

Pre-order / deposit. Add a "founding member" offer to the landing page — access at a discount when you launch. Even $1 of commitment changes behavior. If 5 people pay a $49 deposit for early access, that's stronger signal than 500 waitlist signups.

Manual "Wizard of Oz" version. Manually deliver the service your product will automate. Charge for it. Build the automation later. If no one will pay for the manual version, no one will pay for the automated version.

Concierge MVP. Email your waitlist: "I'm offering this as a hands-on service for the first 10 customers. $X for one month, I handle everything manually." Three paying customers from your waitlist is genuine validation.

Step 5: Set a clear validation threshold before you start

Decide what "good enough" looks like before you run any experiments. This prevents you from moving the goalposts.

Example thresholds:

100 waitlist signups from targeted cold outreach (not followers)
5 pre-orders at $X price
3 paying concierge customers
1 letter of intent from a prospect willing to pay when the product exists

If you hit the threshold: start building the MVP, not the full product. If you don't: revisit the problem statement or ICP, not the solution.

What bad validation looks like

Your network signing up. Friends and followers are biased toward being supportive. Only count signups from people who don't know you personally.
"That's a great idea!" Compliments are not validation. Ignore them.
Waitlist with no intention. A 1,000-person waitlist built from a viral tweet in a tangential community tells you almost nothing about willingness to pay.
Survey responses. Surveys don't capture problem urgency. "I would use this" on a survey is cheap; a credit card number is not.
Building for 3 months before first user conversation. Validation happens before significant engineering investment, not after.

The validation timeline

Realistic timeline: 3-4 weeks

Week 1: Problem statement + find and contact 10-15 potential interviewees
Week 2: Run 5+ discovery interviews
Week 3: Build a landing page, start driving traffic
Week 4: Evaluate results against your threshold, decide to proceed or pivot

If you can't find 5 people to interview about the problem in 2 weeks, the ICP is too narrow or the problem is not widely experienced enough to build a scalable product around.

Frequently Asked Questions

How many customers do I need before I start building?

Three paying customers (or five with strong verbal commitment + deposit) is a defensible signal to start building an MVP. You're not looking for certainty — you're looking for enough signal to justify the next 3-6 months of your time.

What if my idea is too early and no one has the problem yet?

This is rare. "Too early" is usually a reframing of "not painful enough yet." If the problem doesn't exist at scale today, you're making a market timing bet that is almost impossible to time correctly without significant funding. Solve today's problems.

Should I validate with a prototype or a real product?

Neither — validate with conversations and a landing page first. A prototype is engineering time you haven't earned yet. A "real product" takes months. Conversations and a landing page take days.

What if someone else is already building this?

Good. Existing competitors are validation that the market exists. Study them: What do their customers complain about in reviews? Where are the underserved niches? Competition means you need differentiation, not that you need a different idea.

Can I validate B2B and B2C the same way?

B2B validation is more rigorous: you need willingness to pay from a business (budget owner's commitment matters more than an individual's). B2C validation often requires real usage signals (activation, retention, referral) in addition to initial sign-up.

Find tools for launching and growing your indie SaaS at tools.cafe.