Originally published at indielaunch.club
How to Validate a SaaS Idea Before You Build Anything
Most failed SaaS products weren't killed by bad code or poor marketing — they were built for a problem nobody cared enough to pay for. If you're trying to figure out how to validate a SaaS idea, the short answer is this: find at least 10 people who have the problem you're solving, talk to them before you write a single line of code, and ask them what they're currently doing about it — not whether they'd buy your thing. That last part matters more than most idea-stage advice lets on. The rest of this is about what that process actually looks like in practice, where people go wrong, and what "validated" even means at this stage.
Start With the Problem, Not the Idea
Every founder thinks their idea is the thing worth protecting. But the idea is almost never the fragile part — the problem definition is.
When someone tells me they want to validate their SaaS idea, my first question is whether they can describe the problem in one sentence without mentioning their product. Most can't. That's the signal. If you can't articulate the pain clearly and specifically, you're probably building around a vague discomfort rather than an actual, recurring problem someone loses sleep over.
Take the B2B space as an example. A founder building a tool for operations teams at mid-market companies might describe the problem as "teams struggling with workflows." That's too blurry to test anything against. A sharper version: "operations managers at 50-200 person companies are manually reconciling data across three tools every Monday morning, and it takes about four hours." Now you have something you can go find. You can search LinkedIn for those job titles. You can post in Slack communities. You can DM people and say exactly the thing they're already thinking.
The specificity of the problem statement determines whether your validation conversations will give you signal or noise.
The "Just Talk to People" Advice Is Right — and Wrong
You've heard it a hundred times: talk to your customers. And yes, that's true. But the standard framing skips the part that makes those conversations useful.
Most people go into customer interviews asking questions like "Would you use this?" or "Does this sound valuable?" Those questions are almost useless. People are polite. They'll say yes to both because it costs them nothing. According to CB Insights, 35% of startups fail because there's no market need — and a significant portion of those teams did talk to people. They just asked the wrong things.
The question that actually tells you something: "What do you currently do about this problem?" If someone has built a workaround — a spreadsheet, a Zapier hack, a manual process they've documented — that's a person with a real problem. If they shrug and say they haven't really thought about it, you've found someone who doesn't have the problem badly enough to matter.
Ten conversations with people who have genuine workarounds beats a hundred survey responses.
Smoke Tests and Landing Pages: Useful, but Misused
Building a landing page to capture emails before you build the product — this gets treated as the gold standard of lightweight validation. I think it's overrated as a standalone signal.
A landing page with a waitlist tells you that some people found your headline interesting enough to type their email. That's it. It doesn't tell you whether they'd pay, whether the problem is frequent enough to drive retention, or whether the framing you used reflects what they actually care about. Email open rates after signup tend to clarify things quickly — if you send a follow-up asking for a 20-minute call and get a 4% response rate, your list is cold and curious, not warm and committed.
Where smoke tests do work: when you're driving paid traffic and measuring cost-per-signup across different value propositions. If you run $300 in Google ads against three different landing page variants and one pulls signups at $6 each while the others sit at $40+, you've learned something about which problem framing resonates. That's a legitimate signal. A free organic traffic test on a new domain tells you much less.
Validation Method
What It Actually Tells You
Reliability
Customer interviews (10+)
Whether the problem is real and recurring
High
Landing page + waitlist
Whether the headline is interesting
Low–Medium
Paid traffic smoke test
Which value prop resonates, at what acquisition cost
Medium
Pre-sales / LOIs
Whether someone will commit money
High
Survey (50+ responses)
General interest, demographic spread
Low
Building an MVP
Whether people use it repeatedly
High (late stage)
Pre-Sales Are the Closest Thing to Real Validation
This is the step most people skip because it feels uncomfortable.
Asking someone for money before the product exists seems audacious, but it's the clearest test of whether the problem is worth solving. A letter of intent, a refundable deposit, or even a "pay now, get access first" offer filters out polite interest from genuine demand. If nobody will commit $50 or sign an LOI, the conversations where people said "this sounds great" were telling you about your pitch, not your market.
In practice: a B2B SaaS founder targeting HR teams at mid-sized companies might spend four weeks running discovery calls, hear consistent enthusiasm, then ask five of those people for a $500 founding member deposit. If three of them pay it — within, say, a week — that's more validation than six months of building an MVP and watching free users churn.
The deposit model also changes the dynamic of the conversation. People who've paid you something will tell you what they actually need, because now they have skin in the game.
Per the Lean Startup methodology documented by Eric Ries, validated learning requires real feedback from real customers — and financial commitment is the most unambiguous form that takes.
What "Validated" Actually Means
This is worth being blunt about: validation is not a binary state. There's no moment where you've definitively proven the idea will work. What you're doing is progressively reducing the largest risks, one at a time.
The sequence roughly goes: problem exists → problem is frequent and painful enough → people are willing to pay for a solution → your specific approach to the solution is the one they'd choose. Most founders jump from step one to step four, build for six months, and then discover they missed step two or three entirely.
Thirty meaningful conversations and three paying commitments is not a guaranteed market. But it's enough to justify building a narrow first version. Anything less than that, and you're building on opinion.
If you're not doing this before you build, you already know the reason — it's uncomfortable to find out the idea needs work before you've invested in it. But finding out in week four is categorically better than finding out in month fourteen.
FAQ
How many people do I need to talk to before validating a SaaS idea?
There's no universal number, but 10 to 15 in-depth conversations with people who match your target profile is a reasonable minimum for spotting real patterns. Fewer than that and you're mostly working with anecdote. More than 30 in the early stage and you're probably delaying building out of anxiety rather than uncertainty.
Can I validate a SaaS idea without building an MVP?
Yes — and in many cases you should. Interviews, pre-sales, and landing page tests can tell you whether a problem is real and whether people will pay before you write any code. The MVP is a tool for validating product decisions, not market existence.
What's the difference between a problem worth solving and a nice-to-have?
People with a problem worth solving have already done something about it — a workaround, a competing tool they're unhappy with, a manual process they hate. A nice-to-have is something they'd use if it were free and required zero effort. The test is whether the pain is active enough that they've already spent time or money addressing it.
How do I find people to interview for SaaS idea validation?
LinkedIn is the most direct route for B2B — search by job title, send a short message explaining you're researching a problem (not selling anything), and offer 20 minutes of their time. Reddit communities, niche Slack groups, and relevant Twitter/X accounts are also productive, especially if you've posted something useful there first so you're not a stranger.
How long should SaaS idea validation take?
Four to eight weeks is a reasonable window for early-stage validation — enough time for meaningful interviews, a smoke test if applicable, and a pre-sales attempt. Stretching it beyond two months usually means you're avoiding a decision rather than gathering more signal.
Validating a SaaS idea comes down to testing one assumption at a time, starting with whether the problem is real and frequent, then whether people will pay for a solution before they've seen it. Start with 10 conversations, ask about current workarounds rather than hypothetical interest, and treat a pre-sale or deposit as your clearest green light to build.
Top comments (0)