“Validate before you build” is good advice that often becomes useless in practice. Founders who want to know how to validate a SaaS idea hear it, create a survey, get six encouraging responses, and call the market validated. Or they put up a waitlist, buy a few clicks, and mistake curiosity for demand.
There is a better version of the idea: find a place where the problem already has a vocabulary, then invite people to describe it without leading them.
One recent Indie Hackers post is a useful example. The founder had no product, no audience, and no paid marketing. They wrote a Reddit post about payment ghosting among freelancers. In four days, it drew more than 4,200 views and 60 comments. The eventual product idea was a simple one: hold files until a client pays. But the interesting part was not the page-view number. It was that strangers explained the same frustrating situation in their own words.
That is a much stronger starting point than a poll asking, “Would you use my tool?” It is still not proof that people will pay. But it gives you something far more useful than a thumbs-up: language, urgency, objections, and a list of people whose job you may understand well enough to serve.
This is how to run that test without turning Reddit, Slack, Discord, or a niche community into an ad channel.
The distinction that saves months: interest versus evidence
An idea can generate interest for several reasons. It may sound novel. It may solve a problem people recognize in theory. It may be easy to agree with in public. None of those tells you whether a person will change behavior.
Evidence is different. It usually appears as one of these signals:
- someone describes a recent, specific incident;
- someone explains a workaround they use today;
- someone asks when the solution will exist or how it would handle a constraint;
- someone introduces you to another person with the same problem; or
- someone gives you time, data, money, or access to test a solution.
The original freelancer discussion contained a useful kind of detail: people talked about finished work, delayed payment, uncomfortable follow-ups, and clients who disappeared. That is richer than “I would love this.” It tells a builder what is at stake and where the workflow breaks.
Before you post anywhere, decide what evidence you are looking for. If your product is for agencies, you might want to learn how often a specific handoff fails, which person owns the follow-up, and whether the delay costs cash or only creates inconvenience. If your product is for ecommerce teams, you might want to know which report gets rebuilt every Monday and whether somebody would share a redacted version.
The goal is not applause. It is a set of observations you can act on.
What a validated SaaS idea actually means
Validation is not a yes-or-no label that a founder earns from one successful post. It is a chain of evidence. Each link should reduce a different risk.
| Risk | Evidence that reduces it | Weak substitute |
|---|---|---|
| The problem is real | recent stories and repeat workarounds | a broad opinion poll |
| The segment is reachable | conversations in a place practitioners already use | a generic social audience |
| The pain is costly | time, money, risk, or reputation attached to the workaround | “that sounds annoying” |
| A buyer exists | a person can explain who approves spend | comments from non-buyers only |
| A product could win | people will test a narrow solution or make a commitment | a large waitlist with no follow-up |
This distinction matters because you can have strong evidence for one risk and weak evidence for another. A community thread can show that a pain exists, yet reveal that members cannot buy software. Five interviews can show a clear buyer, yet reveal that the problem happens only twice a year. Good SaaS idea validation makes the gaps visible instead of hiding them under a single number.
Use a one-page evidence brief after every validation round. Write the target person, the painful moment, three direct observations, the strongest alternative today, the likely buyer, and the next risk you need to test. If you cannot fill in a field, do not invent an answer. Make that field the purpose of the next conversation.
What 60 comments can and cannot prove
The number 60 is memorable, but it is not a magic threshold. Sixty detailed responses from the right practitioners are useful because they help you see a repeated pattern. Sixty reactions to a generic “would you use this?” prompt are weak because they do not expose behavior.
Use the comment count as a reason to investigate, not a reason to build. The post becomes valuable when it produces three things: language you can test in calls, people who are willing to explain their workflow, and a clear hypothesis about the smallest useful product.
Start with a pain hypothesis, not a feature description
Weak validation posts begin with the product:
I am building an AI dashboard that automates client reporting. Would you use it?
That question asks readers to imagine your solution before they have told you what the problem looks like. It also makes it easy to answer “yes” without offering anything useful.
Stronger posts begin with a narrow moment:
Freelancers: what happens when you have finished the work, delivered the files, and the client stops replying?
That wording does three jobs. It identifies the audience. It names a recognisable event. And it gives people room to disagree, add detail, or tell a story.
Use this simple structure:
- Name the person. Not “business owners”; say “freelance motion designers,” “small agency account managers,” or “Shopify store operators with fewer than five staff.”
- Name the moment. Describe a recent task, failure, delay, or workaround.
- Ask for the current method. Ask what they do now, not whether they like your idea.
- Keep the product in the background. You can say you are researching the topic. Do not force a demo into the opening post.
The more specific the moment, the easier it is for a reader to recognise themselves. Broad questions attract broad advice. Specific questions attract useful stories.
Choose a community where the cost of the problem is already visible
The best community is not necessarily the largest. It is one where members regularly discuss the work you want to understand.
Look for three properties:
| Property | What it looks like |
|---|---|
| Repeated pain | Similar questions or complaints appear every week. |
| Practitioner density | Members actually do the work; they are not only startup spectators. |
| Permission to learn | The rules allow questions, case discussion, or research without promotion. |
For the file-payment example, a freelancer group makes sense because members have first-hand experience of handoffs and late payments. A generic startup forum may produce clever product suggestions, but it cannot tell you whether the workflow hurts in real life.
Spend an hour reading before you post. Search the community for the phrases you expect to hear. Note the popular threads, the recurring advice, and the rules about self-promotion. If the same pain already appears in ten threads, do not post a sales pitch. Bring a sharper question than the ones that have already been answered.
This is also where many founders rush. They see one complaint and immediately build. A better approach is to collect ten examples, then compare them. Are the people in the same role? Are they solving the same version of the problem? Do they have the same ability to pay? A category label is not a customer segment.
How to read 60 comments without fooling yourself
Sixty comments can feel like a verdict. Treat them as research notes instead.
Copy comments into a simple sheet. Remove usernames unless you need to follow up. Add five columns:
- the event that caused the pain;
- the current workaround;
- the consequence of doing nothing;
- the language used to describe the problem; and
- a possible follow-up question.
Then tag each comment. A useful set of tags might include frequent, expensive, embarrassing, manual, existing-tool, buyer, and edge-case.
This turns a messy discussion into a pattern map. You may discover, for example, that the core issue is not payment at all. Perhaps freelancers care most about having a clear approval record. Perhaps the biggest problem happens only with international clients. Perhaps the people who complain loudest are not the ones who choose the software.
Do not count only positive comments. A skeptical comment can be the most valuable line in the thread. “We already solve this through contracts” tells you which users may not need a product. “This would break our approval process” identifies an integration or workflow constraint. “I would not trust a tool to hold my files” may reveal a trust problem that must be addressed before pricing.
The strongest signal is repeated, unprompted language. If ten people independently say they hate “chasing invoices,” that phrase belongs in your notes. It may eventually belong on the landing page. If nobody uses the word you built your product around, your positioning may be talking past the audience.
Move from public signal to private conversation carefully
Public replies are not permission to pitch people in direct messages. Earn the next step.
Reply in the thread with a useful follow-up question. Thank people for the detail. If someone offers a clear story or asks to see what you are exploring, invite them to a brief research call. Keep the invitation optional and specific:
Your point about approvals is exactly the kind of detail I am trying to understand. Would you be open to a 15-minute research call? I am not selling anything yet.
That last sentence matters. If you are early, say you are early. People are often willing to help when you respect their time and do not pretend a rough prototype is a finished company.
The Indie Hackers founder also found that a smaller warm community converted better than cold comments. That does not mean every product needs a private group. It means trust and relevance usually beat raw reach. A ten-person group where members know the workflow can be more useful than a viral post seen by the wrong audience.
Aim for five conversations, not five hundred sign-ups. In each conversation, test your interpretation of the comment pattern. Ask the participant to narrate the last time the issue occurred. Ask what they would need to trust a solution. Ask what would make them keep their current workaround.
Set a validation threshold before you see the results
Founders are good at moving the goalposts after a popular post. Define your threshold in advance.
For a narrow B2B or professional tool, a sensible pre-MVP threshold might be:
- ten or more detailed, on-topic public responses;
- five research conversations with the same type of user;
- a repeated high-cost workflow or failure mode;
- two people willing to test a rough prototype; and
- one form of scarce commitment: a deposit, pilot agreement, access to real data, or a trusted introduction.
For a consumer product, the numbers may be higher and the commitment may look different. The principle stays the same: use a threshold that requires behavior, not sentiment.
The founder in the original story set a goal of 50 sign-ups before building an MVP. That can be a useful local goal, but it is not a universal law. Fifty low-intent emails from a giveaway are weaker than five people who will join a call and describe the problem with receipts. Pick the threshold that matches the cost of building your first useful version.
A five-step community validation sprint
1. Pick one painful moment
Write it as a sentence a practitioner would recognise. Avoid product names and buzzwords.
2. Read twenty existing threads
Look for repeated language, not only market size. Document the people, situations, and workarounds that recur.
3. Post one research question
Use the community rules. Explain that you are learning. Do not include an unsolicited link or ask people to join a list.
4. Turn responses into a pattern map
Tag each response. Separate common pain from one-off stories and separate users from buyers.
5. Earn five follow-up conversations
Run them before designing the full MVP. Let the conversations change your initial idea.
Where this method fails
Community research has limits. Public commenters may be more opinionated than typical buyers. A post can be popular because it tells a dramatic story, not because the product opportunity is large. Some groups also attract people who want free tools and will never pay.
That is why the method is a filter, not a business model. Use it to decide whether a problem deserves deeper work. Then test the first useful outcome with real people, as described in our companion guide on early SaaS customers.
The most valuable result may be a decision not to build. If the comments are scattered, the pain is infrequent, or nobody will spend time on a follow-up, you have learned early and cheaply.
A quick checklist
- [ ] I can describe the pain without naming my product.
- [ ] I chose a practitioner community, not just a large audience.
- [ ] I checked the community rules before posting.
- [ ] My post asks about a current workaround or recent event.
- [ ] I tagged comments for frequency, cost, ownership, and objections.
- [ ] I will speak to at least five relevant people before building broadly.
- [ ] I have defined a behavior-based validation threshold.
The best pre-MVP research does not make you feel certain. It makes your uncertainty narrower. A good thread gives you the words people use, the constraints they cannot ignore, and a small group worth serving. That is enough to build the next test with purpose.
