How to Find Your First SaaS Users Without an Audience
A practical way for solo founders to find early SaaS users: narrow the problem, meet people already dealing with it, invite focused conversations, and look for real use.
Share
The short answer
To find your first SaaS users without an audience, choose one narrow user and one problem they are already trying to solve. Find people discussing that workflow, ask for a short conversation before pitching, and invite a small number of well-matched people to try the workflow with you. Watch what they do and whether they come back. Your first goal is useful evidence, not a launch-day traffic spike.
A launch can make a product visible. It cannot tell you, by itself, whether the right people saw it, whether the problem matters, or whether the product helped. Recent questions in r/SaaS about launching without an audience and r/SideProject about finding users for an AI-built project illustrate how founders can get stuck between building, distribution, and validation. Those threads are anecdotes, not representative research. The process below helps separate those questions for your own product.
Start with a job, not a broad persona
A description such as “small businesses” or “people who use AI” is hard to act on. Write one sentence that names a person, a situation, and a job:
I want to help [specific person] when [specific situation] so they can [observable job or outcome].
For example: “I want to help a solo founder after customer calls so they can turn a recurring pain point into a testable product decision.” The example is only a starting hypothesis; conversations should change it.
Look for signs that the job is real and current:
The person has recently done the task, not just imagined doing it.
They use a workaround such as a spreadsheet, a manual handoff, or a collection of disconnected tools.
The task repeats, creates delay or risk, or blocks something they already care about.
They can show what happened the last time they tried to complete it.
Do not treat agreement with your idea as evidence that the problem is urgent. A recent story about the workaround is more useful than a general compliment. If your product is aimed at technical founders, start with the you can actually support rather than trying to recruit every startup.
S
Specky Team
Writing about AI-native product development at Specky.
Start with places where your intended users discuss the work itself: a niche subreddit, a professional community, product-specific forums, public issue trackers, founder groups, customer calls, or conversations already happening in your network. Search for the task, workaround, failure, or decision—not only for people who say they are looking for a new tool.
Keep the research respectful. Read a community's rules before posting. Answer the question that was asked, disclose your role when relevant, and do not scrape member lists, mass-DM people, or drop a product link into unrelated threads. If a community does not allow recruitment, use another channel.
Make a small list of people who match the situation. Record why each person appears relevant and where you found them. A shorter list with a visible reason is more useful than a large list of loosely matched contacts.
Ask for a conversation before asking for a signup
A short, specific request is easier to answer than a broad request to “try my startup.” For example:
I saw your post about [specific workflow]. I’m trying to understand how [role] handles [task] today. I’m researching the problem, not asking you to buy anything. Would you be open to a 15-minute conversation about the last time you did it?
During the conversation, ask about what happened, not what the person predicts they might do:
“Can you walk me through the last time you had to do this?”
“What did you try first?”
“Where did you lose time or have to make a judgment call?”
“What happened when the workaround failed?”
“Who else was involved in the decision or the work?”
Let the person describe their process before showing your product. If the problem is not present, do not force the conversation toward your solution. Ask what they care about instead, then update the audience or problem hypothesis.
If there is a clear fit, make the next step concrete: offer to set up one real workflow together, ask permission to observe a task, or invite them to a short product test. State what is unfinished and what feedback you need. Do not promise that an early product is production-ready.
Test one workflow with a small group
Choose the smallest product experience that lets a relevant person try to complete the job. It can be a prototype, a manual service behind a simple interface, or a limited beta. The test should answer one question, such as whether the person can complete the task or whether the result changes their next decision.
Ask participants to bring a real task when possible. Give them a clear starting point, then observe where they hesitate, what they ignore, what they try to correct, and whether they can explain the result in their own words. Avoid rescuing them immediately; confusion is useful product evidence.
After the test, ask what they would do next in their actual workflow. If they want to continue, agree on a specific next use and a follow-up date. If they do not, ask what made the workflow unimportant or hard to adopt. A polite “looks great” is weak evidence; a person returning to finish a real task is stronger.
A handful of conversations can reveal whether your assumptions are wrong, but it is not a representative market study or proof of product-market fit. Keep the conclusion narrow: “This workflow repeated in these conversations,” or “We did not reach people who experience the problem yet.”
Separate product interest from distribution
When nobody signs up, do not immediately add features or conclude that the idea has no demand. First ask which step failed:
The right people did not see the page: check reach and channel fit. Find one place where this audience already discusses the job.
People clicked but could not explain who it was for: clarify the audience and problem in plain language.
People understood the offer but did not want a conversation: revisit urgency, segment fit, and the effort of the next step.
People tried it once but did not return: observe a real task and check workflow fit, onboarding, reliability, and ongoing value.
People return with another real task: investigate what prompted repeat use and what still blocks adoption.
These are diagnostic prompts, not universal thresholds. Track the source of each visit or conversation separately from product behavior. If you use analytics, add a source tag or UTM to links you control and compare qualified conversations, completed tasks, repeat use, and signups—not pageviews alone.
Keep a lightweight first-user tracker
A simple table is enough at the start. Avoid collecting personal details you do not need.
Person or account: founder A (illustrative example)
Why they match: handles customer feedback weekly
Recent task or workaround: copies call notes into a backlog
Source: founder group
Test agreed: observe one synthesis task
What happened: rewrote the output before sharing it
Next step: ask which part was unusable
Label observations separately from interpretations. “Used a spreadsheet after every call” is an observation. “Would pay for an AI research tool” is a prediction unless the person takes a concrete step toward buying.
A two-week plan to get started
This is a manageable work plan, not a promise that you will acquire users in fourteen days.
Days 1–2: Write one audience-and-job hypothesis. List the current workaround and the evidence that would change your mind.
Days 3–4: Find a small set of relevant people and note the specific reason each one matches. Identify one or two places where people discuss the workflow and read their rules.
Days 5–9: Request conversations. Ask about recent behavior before showing the product. Keep notes on repeated tasks, workarounds, and contradictions.
Days 10–12: Choose one workflow to test. Invite only people who experience it, explain the commitment, and watch them try a real task.
Days 13–14: Review what happened. Decide whether to narrow the audience, change the problem statement, improve the workflow, or run another test. Write down the evidence and the next question before adding features.
Mistakes that make early-user research noisier
Asking friends whether the idea sounds good. They may be supportive, but support is not the same as a current need.
Treating launch traffic as validation. Visitors can be curious, mis-targeted, or bots; a visit does not show that the product solved a problem.
Posting the same pitch everywhere. This creates noise and can damage trust. Use communities to learn and contribute, and follow their rules.
Recruiting people who only want free software. Free access is not a bad offer, but make sure participants have the problem and agree to a real task.
Building more before understanding the first test. A prototype can confirm that something is technically possible. It does not replace observing the user’s work.
Frequently asked questions
Can I find users before the product is finished?
Yes. You can start with problem conversations before a prototype exists. For a product test, be clear about the current limitations and choose a workflow that is safe to test. Do not imply that an unfinished product is ready for critical or sensitive work.
How many people should I talk to?
There is no universal number that proves demand. Start with a few people who closely match the situation, look for repeated patterns and contradictions, then recruit again if you still cannot distinguish between competing explanations. Small qualitative samples help you learn; they do not estimate the whole market.
Is Reddit a good place to find first users?
Reddit can help you find people discussing a problem, but each subreddit has its own norms and promotion rules. Search for relevant problem discussions, contribute a useful answer, and ask for research participation only when allowed. Avoid generic promotional posts and unsolicited mass messages.
Should I offer the beta for free?
A free test can reduce friction, but define the task and commitment. Track whether someone uses the product for real work and returns. If willingness to pay matters to your business model, test an honest pricing conversation separately rather than assuming free usage proves purchase intent.
What should I do after the first conversations?
Turn recurring observations into a clear problem statement, then decide what to test next. The product problem statement template can help separate evidence from assumptions. If you have a problem worth specifying, use the free AI PRD generator to create a draft that your team can review. For the validation loop after a prototype exists, see the seven-day product validation plan.
The first users are a learning loop
Finding first users is not a trick for manufacturing demand. It is a focused way to reach people who already do the work, understand their current behavior, and see whether your product helps them complete a real task. Start with one audience, one job, and one honest invitation. Let what people do shape the next version.