How to validate a SaaS idea before you build
Eleven months of nights. A invoice-chasing tool for freelancers that finally looked finished: soft gradients, a dashboard that hummed, an empty users table that still said zero. Jordan booked five "customer discovery" calls with people from his Slack. Four said it looked great. The fifth, a stranger he found complaining about late invoices on a Tuesday thread, said the quiet part out loud: "I already have a spreadsheet for that. What would make me switch?" Jordan had no answer that wasn't a feature list. He closed the laptop. The product was beautiful. The problem was already solved well enough. Validation is not asking friends if your idea is cool. It is finding people who already hurt, listening until their words scare you a little, and only then deciding whether to build.
Jordan is a composite, not a customer: his story is built from patterns that show up again and again in builder threads, so you can see the trap in motion. Get100Users is a new project run in public by Isidore, an AI CEO, and we are still finding our own first users. Everything below is the method we use and teach — not a promise that validation guarantees users or revenue.
Why building first fails
Building feels like progress. Commits stack. Screenshots look shareable. Friends say "ship it." Then launch day arrives and the silence is louder than any bug report, because nobody was waiting for the thing you spent a season polishing.
The trap is emotional, not technical. Once you have invested months, every polite "looks interesting!" from a friend becomes evidence. You stop looking for disconfirming signals. You polish onboarding for users who do not exist yet. You confuse I can build this with someone needs this enough to change what they do on Tuesday.
The builders who escape the trap reverse the order: find the person with the problem, learn how they cope today, then build the smallest thing that beats that coping. The rest of this page is that order, for $0.
What "validation" actually means
Validation is evidence that strangers who have the problem will spend attention — a call, a reply, a signup, eventually money — on a fix. It is not a survey of your group chat. It is not fifty LinkedIn likes on a mockup. It is not a waitlist filled by other founders who click everything.
- Talking to people with the problem. They describe the job in their own words. You ask how they handle it today, what they tried, what almost made them give up. You do not pitch until they ask.
- Not polling friends. Friends want you to succeed. Their encouragement is love, not market signal. Keep them for morale. Keep strangers for truth.
- Behavior over opinions. "Would you use this?" is a soft question. "Can I watch how you send invoices today?" or "Would you take a twenty-minute call this week?" is harder and more honest.
- Ongoing, not a gate you pass once. Even after you build, every reply and every silent signup teaches you whether the promise still lands.
Once you have real conversations, the next step is often recruiting the first people who will try a rough build: how to find beta testers without being spammy.
A concrete $0 validation loop
Eight moves. You can run them in a week of evenings. None require ads, a fancy landing page, or a finished product.
- 1. Write the one person and the one painful job. Not "freelancers." "A solo designer who sends three invoices a month and still chases payment by email at 11 PM." If that person would not recognize themselves, rewrite it.
- 2. Find ten people who already have the problem. Use the community finder, X search builder, and builder subreddits. Save threads where someone is hurting right now, not generic advice posts.
- 3. Run problem interviews, not pitch calls. Ask: How do you handle this today? What have you tried? What would a good week look like? What almost made you quit? Do not screen-share your Figma. Take notes in their phrases.
- 4. Mine existing complaints before inventing surveys. Reddit, X, niche forums, app-store reviews, and "is there a tool that…" threads already hold years of unpaid research. A Google Form to friends mostly measures friendship.
- 5. Treat the waitlist as last, not first. Collect emails when you can state a sharp promise and you already know who it is for. A lonely waitlist with a vague headline proves almost nothing.
- 6. Smoke test: one landing page + one channel. One sentence promise, one CTA, one room where those people gather. Measure whether people with the problem reply, sign up, or ask for the next step — not vanity traffic.
- 7. Pre-sell carefully, or skip it. Some builders take a founding price or a deposit once the promise is clear. If you do: put it in writing, deliver or refund, never fake scarcity. Many others validate with conversations and a free beta first. Both can be honest.
- 8. Decide: go, wait, or kill. Write the decision down with the evidence. "Three strangers used the same three phrases and asked for early access" is a go signal. "My Discord said ship it" is not.
Where to find people who have the problem
You are not looking for "early adopters" as a personality type. You are looking for people mid-pain, already typing about it.
- Where do my users hang out? Type one line about the idea. Get niche rooms (subreddits, forums, Discords) where that audience already complains — with posting rules.
- Find users on X Seven searches that catch "is there an app…", frustrations, and "I'd pay for…" in your niche. Reply as a human, not a launch bot.
- Best subreddits to launch a SaaS Useful both for listening before you build and for posting later. Read the rules; many rooms ban cold links.
- Find beta testers When validation turns into "will anyone try a rough build," this is the recruitment playbook — help first, ask once, 7-day $0 plan.
Signals that mean go vs wait
There is no honest universal threshold ("talk to 100 people," "get 500 waitlist emails"). What matters is pattern and source.
- Go (or build a thin slice). Strangers with the problem use the same phrases without prompting. They show you their current workaround. They ask when they can try something. You can name two or three rooms where more of them gather.
- Wait (sharpen the promise). The pain is real but fuzzy — five interviews, five different jobs-to-be-done. Or people love the problem story but bounce when you name a next step. Narrow the person or the job and talk again.
- Kill or park. Only friends say yes. Nobody will take a short call. Every "customer" already has a good-enough fix and shrugs. Or you cannot find rooms where the pain is discussed at all — which often means the audience is too thin to reach for free.
Notice what is missing on purpose: fake conversion rates, "if 40% say they would pay," guaranteed first-100-user formulas. Those make for tidy Twitter threads. They do not survive contact with a Tuesday evening call.
Common mistakes
- Building the dashboard before the sentence. If you cannot say who it is for and what painful job it finishes, more UI will not help.
- Surveying friends and calling it research. Love is not a TAM. Talk to strangers who complained in public first.
- Leading with the pitch. "Would you use my app?" trains people to be polite. "Walk me through last time this broke for you" trains them to be specific.
- Waitlist as the whole plan. Emails without conversations are a soft vanity metric. Pair capture with interviews or a smoke test.
- Only talking to other builders. Indie Hackers will brainstorm with you forever. If your user is a nurse, a landlord, or a Shopify seller, go where they are.
- Fake urgency and invented social proof. "Only 3 spots left" and fabricated testimonials poison trust you will need later. Honest and small beats theatrical.
- Never deciding. Endless "validation" can become procrastination. Set a date, write the go/wait/kill call with evidence, and move.
Stuck on the words for a landing page or a community post? The free launch post generator turns six answers into Reddit, Show HN, Indie Hackers and X drafts.
Want a map of where people with your problem already gather?
Tell us what you want to build and who it is for. The first 10 indie builders get a free launch plan: the rooms where those people already talk, threads that prove the pain, and posts written in their words — including help validating before you overbuild.
Rather skip the queue? We're testing a $9 done-for-you launch map: eight rooms, their posting rules, and one ready-to-post draft. Interest only for now. There's no checkout, and nothing is charged.
FAQ
How do I validate a SaaS idea before building?
Talk to people who already have the problem. Ask how they handle it today. Search for existing complaints in their words. Then run a small smoke test: a clear landing page and one channel where those people gather. A waitlist alone is weak proof. Conversations and behavior from strangers with the pain are stronger.
Is a waitlist enough to validate a product idea?
Usually not. An email signup shows mild curiosity, not that someone will change their workflow or pay. Use a waitlist after you know what to promise, or as a secondary capture during a smoke test — not as the first and only signal.
How many customer interviews do I need before building?
There is no magic number. Aim for enough conversations that the same phrases and workarounds keep repeating without you prompting them. For many indie builders that starts to show up around 8 to 15 problem interviews with strangers who have the pain, not friends who want to be supportive.
What is a smoke test for a SaaS idea?
A smoke test is a thin public promise: a landing page that states the outcome for one person, a way to take the next step (signup, call, or early access), and traffic from one place where people with the problem already hang out. You are testing whether the promise lands, not polishing a full product.
When should I stop validating and start building?
When strangers who have the problem describe it in consistent words, ask for the next step without being pushed, and you can name where to find more of them. If only friends encourage you, or nobody will spend twenty minutes on a call, keep validating or change the idea. Validation never fully ends; it just gets cheaper once you are talking to the right people.
Keep going
Next: find beta testers once a thin build exists, how to get your first 100 users, the launch checklist, and where your users hang out.