How to Find Beta Testers

Twelve people, opted in, for fourteen straight days. That's the actual number Google writes into its own policy before a personal developer account can touch a live production button.

Most people trying to find beta testers already have a finished build and an empty spreadsheet.

What they don't have is a source. So the plan becomes one Reddit post, or a link dropped into a Discord server, followed by a lot of refreshing.

The real answer starts closer to home than that. The fastest testers to find are the people who already know your name. The slowest, least reliable ones are the strangers you're about to go recruit from a subreddit.

Both matter, in a specific order. Here's what each source costs, and what Apple and Google actually require before either one lets your app past the testing stage.

What Counts as a Beta Tester, and What Doesn't

A beta tester is not a download number.

Someone who installs your app once, opens it for eleven seconds, and never comes back is a bounce, not a tester. Counting them toward anything is how founders convince themselves a test went fine when it didn't.

A real beta tester does three things. Installs the actual build, not a demo or a mockup. Uses it more than once, across more than one day. Tells you something specific enough to act on.

"Looks good" is not feedback. "The signup button did nothing on my Pixel until I rotated the screen" is.

That distinction matters because Apple and Google measure it too, just for different reasons. Google's own guidance for personal developer accounts is blunt about what happens when testers don't actually engage: if too few stay opted in, or the ones who do aren't using the app the way real users would, Google can require more testing before it grants production access, even after you've technically hit twelve names on a list.

So the count you're chasing isn't twelve installs. It's twelve people who keep the app on their phone for two weeks and actually open it.

That's a much smaller pool of favors to call in than it sounds, and it changes who you ask first.

One more distinction worth setting now: a beta tester isn't the same audience as a launch-day customer. A tester's job is to break things and complain. A customer's job is to pay. Recruiting for one with the pitch meant for the other is why half of these campaigns fizzle before day three. The startup launch checklist is worth a look if you haven't separated those two lists yet.

Start With the List You Already Have

Before any community, any platform, any paid service: go through your own contacts first.

Not a mass email. A short list, hand-picked.

Pull thirty names from three places. Existing customers or waitlist signups. People who've replied to something you've posted online in the last year. Colleagues or former coworkers in a role close to your target user.

Thirty names, not three hundred. The quality of the ask matters more than the volume here.

Message each one individually, or in small batches of five inside a shared context like a work Slack channel or a group chat. Never a blast BCC.

The message has three parts. What the thing is, in one sentence. What you specifically want ("use it for real, for one task this week, and tell me where it broke," not "try it out"). A hard deadline, seven to ten days out.

Here's the arithmetic that makes this worth doing first. A cold post in an unfamiliar community typically converts under 2% of viewers into an installed, engaged tester, if it converts at all. A direct, personal ask to someone who already knows you lands closer to one in three.

Thirty personal messages at that rate gets you to Google's twelve-tester floor on their own, without touching a subreddit.

The failure mode here isn't a low response rate. It's asking too broadly and getting installs with no follow-through: five people say yes, open the app once, and go quiet.

Fix it by naming the specific task up front. "Test the checkout flow with a real card, not a real purchase," not "poke around." A task with an edge gets a task-shaped answer back.

If your list is this thin, that's a five-to-ten-minute job, not a week's project. Do it before reading the rest of this, then come back for where the other testers come from.

Where to Find Beta Testers When You Have Zero Users Yet

Once the personal list is exhausted, the next fastest testers are strangers who've already opted into the ritual of trying new, unfinished things. That's a narrower group than "the internet," and it lives in a handful of specific places.

Reddit is the biggest one, and its etiquette is stricter than it looks. Communities built for project-sharing tolerate a self-promotional ask as long as it reads like a project update: what you built, why you built it, and what's rough about it right now. What none of them tolerate is a bare link with no context.

Voting is where people get burned. Reddit's own guidance is explicit: you should never ask for votes, on Reddit or anywhere else, and doing so risks the account or the domain getting banned outright. Post once. Engage with every comment for the first day. Don't repost the same build to the same community inside a month.

Indie Hackers works on the same principle, with a longer memory. A "Show IH" or milestone post gets read by people who've seen a hundred of these and can tell a real ask from a launch-day dump. If you're trying to build a recurring source of testers rather than a one-time list, the launch platforms indie hackers actually use covers which communities reward that consistency and which ones bury a second post from the same account.

Directory and pre-launch sites are a smaller but real source, particularly for a product still in beta rather than fully shipped. A handful are built specifically for early, unfinished products, and the BetaList alternatives worth checking this month breaks down which ones actually route traffic to a signup form versus which ones are mostly for show.

The math on strangers is worse than the math on your own list. It should be.

Expect single-digit conversion from a community post to an actual, engaged tester. Expect most of that yield inside the first 48 hours, then a hard stop. That's fine. Strangers aren't there to hit twelve fast. They're there to widen who's testing beyond the people who already like you, which is the group most likely to be too polite to report the real problems.

What Paid Recruiting Platforms Actually Charge

When the free routes are too slow, or you need testers who match a specific profile rather than whoever happens to be scrolling, a handful of platforms sell exactly that.

That last row deserves a direct warning. Several services now exist to sell "12 testers, 14 days" as a checkbox for Google Play, and the price is genuinely low.

The problem is what Google is actually checking for. Not twelve opt-ins. Twelve people opted in continuously and using the app the way a real user would.

If the reviewer looking at your application sees tester activity that reads as bought rather than engaged, Google's own next-steps guidance says continued testing can still be required, even after the twelve-and-fourteen numbers are technically met. Paying for the number without the behavior behind it is a coin flip, not a shortcut, and a rejected application often costs more time than the service saved.

The honest budget line for most solo founders: spend nothing until the free routes are exhausted. Spend on a targeted platform only when the product genuinely needs a specific kind of tester, like a particular phone, a regulated industry, or a language your own network simply doesn't cover.

Meeting Apple's and Google's Testing Requirements Without Faking It

If the product is a mobile app, the store you're shipping to sets a hard floor on tester count. Worth knowing the exact number before you recruit a single person.

For Android, the rule applies to any personal Google Play developer account created after November 13, 2023: a closed test with at least 12 testers opted in continuously for the preceding 14 days, before the Dashboard's "Apply for production" button even works.

Google's own documentation lays out three testing tracks. Internal testing is instant and optional, for a handful of people you trust completely. Closed testing carries the 12-and-14 requirement. Open testing only becomes available once production access has already been granted. Business accounts verified with a D-U-N-S number skip the requirement entirely, worth knowing before you spend a weekend clearing a threshold you never needed to clear.

The steps, in order:

1. Set up an internal testing track first and add three to five people you trust completely. This is instant, and it catches the obvious breakage before anyone outside your circle sees it.
2. Create a closed test track once the build is stable enough to survive a real session, and start adding testers.
3. Track the 14-day clock from the moment your 12th tester actually opts in, not from when you upload the build or create the list. A tester who opts out and back in resets their own contribution to the streak.
4. While the clock runs, ask every tester to use at least two or three distinct features, not just open and close the app, and report anything odd through one shared channel.
5. Apply for production access only after the 14 days close. Answer honestly how easy recruiting actually was and whether tester behavior matched real users; Google reads that section, and a vague or inflated answer is a common reason applications bounce back for more testing.

For iOS, the numbers are bigger and the mechanics are different. TestFlight allows up to 100 internal testers and up to 10,000 external testers per app, invited by email or a public link. Only your first build needs a full App Review before testers can install it; later builds usually clear faster. A build stays testable for 90 days from upload, longer than almost any beta cycle needs, so expiration is rarely the real constraint.

The real ceiling on TestFlight isn't Apple's cap. It's your own ability to read feedback from that many people.

Centercode's own analysis of the 10,000-tester limit makes the point plainly: the number is an upper bound Apple set on the platform, not a target worth chasing. A small, engaged group of fifty to a hundred testers who actually use the product produces more usable feedback than a few thousand who install it once and forget it exists. Aim for engagement over headcount, on either platform.

What to Ask Testers So Their Feedback Is Usable

A tester told to "try it out" will do exactly that. Try it once. Shrug. Say it's fine.

The quality of what comes back is almost entirely a function of what you asked for, not how many people you asked.

Send every tester the same short brief, not a form they fill out cold.

• One specific task to complete this week, described as an action: "create a project and invite one collaborator," not "check out the collaboration feature."
• One question about where they got stuck, with a request for the exact screen or step.
• One question about what they expected to happen versus what actually happened.
• A single place to send it back. One email address, one form, one shared thread. Never three channels for the same test.

Set the response window to three or four days after the task is assigned, not "whenever." A brief with no deadline gets answered the day the app is uninstalled from a full phone, if it gets answered at all.

Read every response the day it lands, and reply to each one, even with a single line.

Testers who get acknowledged report more. Testers who feel ignored after round one go quiet for round two, right when the feedback usually gets sharper.

Google's own guidance to developers makes a related point from the other direction: apps that come out of active, well-managed testing tend to see fewer low ratings and fewer early uninstalls after launch, because the rough edges got fixed while only testers could see them.

Keep the same brief format for every round of the beta, even as the app changes. A tester who's answered the same three questions twice already knows the shape of what you need on the third round, and that familiarity is worth more than a fresh form every time.

When You Have Enough, and What to Do With Them Next

Enough testers isn't a fixed number. It's the point where three or four sessions in a row stop surfacing anything new.

For most single-feature apps, that plateau lands somewhere between fifteen and thirty engaged people. For anything with real complexity underneath, closer to fifty.

When you hit it, don't keep recruiting out of habit. Close the loop instead.

Tell every tester what changed because of their specific report. Thank them by name if they'll let you. Ask the ones who stuck around through the whole cycle whether they'd like early access when it ships.

That group becomes your first real customers, and your first word of mouth, at the cost of one message.

One last piece worth naming plainly: recruiting testers and getting noticed on launch day are two different problems, and people often try to solve both with the same Reddit post. Testing needs a small, engaged group willing to complain about a rough build. Launch day needs reach, and reach is something you can simply buy a rank for. The Board is a public leaderboard of brands where placement is sold outright and disclosed as a paid position, sorted by nothing but the amount paid, and a listing there puts your product in front of people who might volunteer as testers before they're ever asked to be customers. It's one more channel worth having in the mix, never a replacement for the personal list you should already be working through today.

The order doesn't change either way. Your own list first. Strangers in the right communities second. A paid platform only if the product genuinely needs a profile your network doesn't have. The store's actual numbers treated as a floor to clear honestly, not a box to check with money.

Everything in the startup launch checklist assumes this step is already done, and most of what goes wrong on launch day traces back to a beta that was too small or too rushed to matter. The full how to launch a startup guide picks up from there, and once the testers are in, the directories worth submitting a startup to is the next move for turning a finished beta into a real audience. The Launches category has the rest of what's planned and written under the same rotation.