How to find beta testers

Four months of evenings. 212 commits. A shift-scheduling app for night nurses that finally, quietly works. Maya opens a spreadsheet, pastes in forty names she half-knows from X, and sends the same message forty times: "Hey! Would you beta test my app? Would mean a lot 🙏" By Sunday, three people have answered. One says "maybe later." One asks what it is. One says "unsubscribe," which is not even a thing in DMs. Then, on a slow Tuesday, she does something different. She searches r/nursing for "swap shifts" and finds a nurse at 3:12 AM, typing that she has traded the same Saturday four times by group text and still doesn't know who's covering. Maya doesn't send a link. She asks one question. Two days later that nurse is her first beta tester, and she brings two coworkers. Beta testers aren't hiding. They're describing your product right now, in their own words, in rooms you haven't opened yet.

Maya is a composite, not a customer: her story is built from patterns that show up again and again in builder threads, so you can see the move 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, not a promise of numbers.

Find the rooms where your testers are →

Still deciding whether to build at all? Start with how to validate a SaaS idea before you build.

Why "will you beta test my app?" fails

That message asks a stranger for a favor before you have given them a reason to care. It doesn't say who the app is for, so nobody recognizes themselves in it. It costs them an evening and offers them nothing they asked for. And it lands in an inbox that already holds a dozen messages that look exactly like it.

The fix isn't a cleverer DM. It's a different order of events: find the person who already has the problem, help them with it, and let the beta be the answer to something they said. When the ask arrives after the problem, it stops being a favor and starts being an offer.

Where beta testers already hang out

There are two kinds of rooms, and you want both, for different reasons.

1. Your users' rooms (where fit is proven)

These are the places where people who have your exact problem go to complain about it: a niche subreddit, a trade forum, a Discord, a Stack Exchange site, a search on X. Testers from here are slower to find and worth ten times more, because when they keep using your app, it means something. We've mapped these rooms, with posting rules, for 23 audiences:

Developers, self-hosters and AI tool users: people who will file a bug report with a stack trace, if you let them.
No-code builders, productivity fans and designers: they have tried every tool in your category and will tell you exactly where yours is different.
Freelancers, Shopify sellers, small B2B teams and marketers: they pay for software, and they measure it in hours saved.
Teachers, parents, fitness communities and people managing their own money: rooms where a link from a stranger is unwelcome, and a genuinely useful answer is remembered.

Not on the list? The full finder covers 23 niches, from indie game devs to landlords.

2. Beta-curious rooms (where people like trying new things)

These rooms are full of early adopters and fellow builders. They are wonderful for finding bugs, testing onboarding, and getting a first wave of honest reactions. They are weaker at telling you whether real customers will stay, because many testers here aren't your user. Use them for polish, not proof.

BetaList: built for products that are real but not finished. The free queue can take weeks, so submit on day one of your beta, not the day you need people.
r/alphaandbetausers: a subreddit whose whole point is recruiting testers. Say who it's for, what feedback you need, and what testers get.
r/SideProject and Indie Hackers: builders who will try your product if you tell the story of building it. Lead with the story, not the link.
Show HN: for anything people can try right now, especially developer tools. Brutal, useful, one shot. Read how to do a Show HN first.

More rooms: 12 Product Hunt alternatives, best subreddits to launch a SaaS, and 31 free launch directories.

3. X, where people describe your product without knowing it exists

Somewhere tonight, someone is typing "is there an app that…" followed by a description of your app. They will get a joke and a GIF. Search for those moments instead of broadcasting into the void. The X search builder writes seven searches for your niche in one click: frustrations, "is there a tool," "I'd pay for," and the rest.

How to ask without pitching

The whole method fits in three messages. Each one has to earn the next.

1. Answer the problem. Reply where they posted, in public, with something useful even if they never try your app: a workaround, a template, the setting they missed. No link. If you can't help without your product, you aren't ready to reply yet.
2. Ask one real question. "How are you handling it now?" or "What did you try before this?" Then listen. Their answer is worth more than their signup, because it contains the exact words for your landing page.
3. Offer, honestly, once. Only if they still want a fix: "Full disclosure, I'm building a tool for exactly this. It's in beta and rough in places. Want early access? No pressure either way." Disclose that you made it. Every time.

Here's an example public beta post, in Maya's voice, that follows the same rules, for rooms that welcome them (r/alphaandbetausers, Indie Hackers, a Discord's #share channel). Rewrite it in your own voice:

Looking for 10 night-shift nurses to break my scheduling app
I'm a solo builder. Last month a nurse here described trading the same Saturday shift four times by group text and still not knowing who was covering. I couldn't stop thinking about it, so I built a small app where you post a shift, coworkers claim it, and your charge nurse approves it in one tap. It works, but so far it has only been used by me and one very patient nurse. I'm looking for 10 people who swap shifts at least twice a month. You'd get free access for as long as the beta runs and my personal email, and I'll fix whatever annoys you first. I'd love to hear the brutal version. What would stop you from using something like this?

Notice what it does: names the exact tester, tells a true small story, admits it's rough, says what testers get, and ends with a question instead of a link. Swap in your own true details. Never borrow a story that isn't yours.

What to offer beta testers (honestly)

Testers give you their scarcest thing: attention, on a product that will sometimes break. Pay them back with things that are real.

Early access, for free, for the length of the beta. Say when the beta ends, or say you don't know yet. Both are fine. Surprise invoices are not.
A direct line to you. Your email, a private channel, a reply within a day. For an early tester, being heard by the person who can fix it is often worth more than any discount.
Credit, if they want it. A thank-you in the changelog or on a "built with" page. Ask first; some people would rather stay private.
Real influence on the roadmap. Only promise it if it's true. Then prove it: when you ship something a tester asked for, tell them by name.
A founding price, maybe. If you offer one, put it in writing and honor it. A lifetime deal you can't afford to keep is a debt, not a gift.

What not to offer: gift cards for signing up (you get people who want gift cards), fake scarcity ("only 3 spots left!" when there are 300), or a feature you haven't built yet.

A 7-day beta recruitment plan ($0)

Day 1. Write the one sentence. Not "founders" or "small businesses." "A night-shift nurse who swaps shifts by group text at 3 AM." If your tester wouldn't recognize themselves in it, rewrite it. Submit to BetaList today, because its queue is slow.
Day 2. Map ten rooms. Use the community finder for your niche, then add the beta-curious rooms above. For each room, write down the link, the self-promotion rule, and the day it allows sharing.
Day 3. Listen. Search each room for the problem in your users' words. Run the seven X searches. Save every thread where someone is struggling right now. You are looking for twenty real moments, not twenty usernames.
Day 4. Help ten people, with no links. Reply to ten of those threads with something genuinely useful and one honest question. This is the day that feels slow and matters most.
Day 5. Open one door in public. Post one honest beta call in a room that allows it, like the example above. One room, one post, written for that room. Then answer every reply like it's the only one.
Day 6. Onboard by hand. Write to every tester yourself. Ask one question: "What almost stopped you from signing up?" Fix that answer this week, and tell them you did.
Day 7. Count, then choose. Which room produced testers who came back a second time? Not who signed up, who came back. Go back to that room next week with what you learned, and let the others go quiet.

Mistakes that kill response rates

Forty identical DMs. People can smell a template from the first three words. One message written for one person beats forty pasted ones, and it doesn't get your account limited.
A link in the first message. On most platforms a link from a stranger reads as spam before it reads as anything else. Earn the second message first.
"Any feedback welcome!" Vague asks get vague answers, or none. Ask one specific thing: "Did the import work on your file?"
A fourteen-field signup form. Every field is a reason to leave. Ask for an email and one question, and get the rest in conversation.
Recruiting only builders. Other indie hackers are generous testers, but if your user is a nurse, a hundred founders telling you it looks great proves very little.
Breaking a room's rules. Read the sidebar, the pinned post, the promo-day schedule. One removed post can close a room for months.
Going quiet after they sign up. The fastest way to lose a tester is to let their first bug report sit unanswered for a week. Reply the same day, even if the fix takes longer.

Stuck on the words? The free launch post generator turns six answers into Reddit, Show HN, Indie Hackers and X drafts.

Want us to find your first ten testers' rooms?

Tell us what you built and who it's for. The first 10 indie builders get a free launch plan: the rooms where your users already gather, the threads that prove it, and a beta post written in their words.

Apply for free Launch help →

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

Where can I find beta testers for free?

Start in the rooms where your real users already complain about the problem: a niche subreddit, a Discord, a forum, a search on X. Then add the beta-curious rooms, BetaList, r/alphaandbetausers, r/SideProject, Indie Hackers and Show HN, for people who simply enjoy trying new things. All of them are free to join. Read each room's rules before you post.

How many beta testers do I need for a SaaS?

Fewer than you think. A handful of people who actually have the problem and use the product every week will teach you more than hundreds of signups who never log in twice. Aim for 10 to 20 active testers first, and watch for the moment three of them report the same thing without being asked.

How do I ask people to beta test without spamming them?

Answer their problem before you mention your product. Reply to the thread where they described it, ask one honest question about how they handle it today, and say plainly that you are building something for it. Offer access only when they ask, or when they clearly want a fix. One person, one message, written for them.

Should I pay beta testers?

Usually not at the start. Paying strangers attracts people who want the payment, not the product. Offer what is real instead: free access during the beta, a direct line to you, credit in your changelog if they want it, and a genuine say in what you build next. If you promise a founding price, put it in writing and honor it.

How long should a SaaS beta last?

Long enough for testers to hit the real workflow a few times, often two to six weeks. End it when the same complaints stop showing up and people start asking how to pay, not on a date you picked before anyone used it.

Keep going

Next: validate the idea before you overbuild, how to get your first 100 users (what to do once your testers start sticking), how to find your first users on X, best subreddits to launch a SaaS, how to launch on Reddit without getting removed, and the launch checklist for when the beta ends.