How to Find Beta Testers With No Audience

With no audience, you find beta testers by working a ladder from easiest to hardest: the handful of people who already replied to something you posted, other builders who will trade a test for a test, communities you have been a member of for months, individual people you can see publicly complaining about the problem you solved, and last, public beta surfaces like a TestFlight link, a Google Play open track, or a showcase listing. The first four rungs give you opinions. The fifth gives you installs. You need about five people per round, not fifty, and you get them by asking one at a time with a specific, small, dated request.

Why do tester lists assume an audience you don't have?

Open almost any guide to recruiting beta testers and the first three items are "email your existing customers", "post to your list", and "run a small ad campaign". Those work. They also describe a product that already has customers, a list, and a budget, which is not the situation of someone who finished the build last Thursday.

The reason the advice skews that way is that most of it is written by agencies, product vendors, and recruiting panels whose reader is a product manager at a company with a mailing list. Their version of "zero audience" is a new feature at a company with ten thousand users. That is a genuinely different problem.

The zero-audience problem is narrower and more solvable than it looks. You do not need a channel. You need about five people who have the problem, in the same week, willing to spend twenty minutes. Every rung below is a way of finding five people, and they are ordered by how hard it is to get one and how good the answers are once you do.

Which sources produce feedback you can build on?

Here is the ladder. Work it top down and stop as soon as you have enough for the round you are running.

Rung	Where the people come from	Effort per tester	What you get back	The trap
1. People who already replied	Anyone who commented, replied, or DMed you about the build in the last few months	Very low, one message	Warm, honest, specific. They already opted in by talking to you	Broadcasting to them as a group instead of writing individually. It reads as a mailing list and gets the response rate of one
2. Builder favour trades	Other makers shipping at the same stage, in trade communities and build-in-public circles	Low, one exchange	Sharp on interface, onboarding, copy, and bugs. Fast turnaround	Builders review the build, not the problem. They will tell you the empty state is weak and cannot tell you whether anyone would pay
3. Communities you are already in	A Discord, a subreddit, a Slack, a forum where you have months of history	Medium, one post plus replies	Domain-accurate. These are people with the actual job	Posting as a stranger. If your first post in three years is a link to your app, the room reads it as an ad, correctly
4. Individuals with the problem, in public	Forum threads, support boards, and posts where someone describes the exact pain your app removes	High, one message each, low reply rate	The strongest signal you can get. If these people say no, the problem may not be worth solving	Templating it. The moment the message could have been sent to anyone, it converts like spam, because it is spam
5. Public beta surfaces	TestFlight public link, Google Play open testing, showcase listings, beta directories	Low per head, high setup	Volume, install and crash data, occasional gold	Anonymous installs give you clicks, not opinions. A hundred silent installs teach you less than one recorded session

Two things about that order. First, effort per tester rises as you go down and so does the value of what you learn, right up until rung five, where effort drops and so does depth. Second, rungs one through four are conversations and rung five is a funnel. You want conversations first, because a funnel with no conversations behind it just produces a number you cannot act on.

Rung 1: the people who already replied

Go back through the last few months of anything public you did. A launch thread, a comment you left that got replies, a DM from someone who said "let me know when it's ready". Most makers have between five and fifteen of these and have never counted them. That is usually the whole beta.

The ask is one message, in the same place the original conversation happened, referencing the original conversation. Not a broadcast.

Rung 2: builder favour trades

Test-for-test is the fastest rung to work, because the person you are asking wants the same thing you do. Trade communities exist for exactly this: Favors.dev runs on builders swapping small acts of help, and a twenty-minute test in each direction is one of the cleanest trades available.

The honest caveat is what this feedback is good for. Builders are excellent at spotting a confusing first screen and terrible proxies for your actual user. Use rung two for craft and rung three or four for whether the thing matters.

One warning specific to Android. Mutual-install pools, where everyone installs everyone else's app to satisfy a requirement, are a different activity from a genuine test, and Google's production access rules are about testers who are actually opted in. The compliant version of that whole exercise is in Google Play 12 testers: how to find real ones.

Rung 3: communities you are already in

The word "already" is carrying the sentence. A community where you have history will help you. A community you joined yesterday will not, and it will be right not to.

If you have no such community, that is a real gap and the fix takes weeks, not hours: pick one room where your users are, spend a month answering other people's questions, then ask. If you need testers this week, skip to rung four.

Rung 4: individuals with the problem, in public

This rung is slow and it is the only one that tells you whether you built something people want. Somewhere there is a thread where a person describes, in their own words, the exact frustration your app removes. That person is worth thirty anonymous installs.

Expect a reply rate that would look terrible in a marketing dashboard. Ten well-chosen, individually written messages producing two or three replies is a good result. The value is in the two, not the ten.

Rung 5: public beta surfaces

Once you have a build worth pointing strangers at, open the taps. Apple's TestFlight lets you invite up to 10,000 external testers and up to 100 internal ones, and a public link means people can join without you collecting a single email address. Google Play's open testing track does the same job on Android. A permanent listing in a showcase adds a page people can find months later, when a launch thread has long since scrolled away.

Treat everything here as top-of-funnel. It fills the room. It does not have the conversation for you.

What about paid tester panels?

They are a real service and they are honest about what they sell, which is recruited participants matched to a demographic brief. What they cannot sell you is someone who wants your product. A paid tester completes a task list because they are paid to complete a task list. That produces usable usability findings and produces nothing at all about demand.

If your question is "can a person aged 40 to 55 complete signup on an Android phone", a panel answers it. If your question is "does anyone care", no amount of money makes a panel able to answer that. Separately, avoid any service selling installs, opt-ins, or ratings for app store requirements. That is the category that costs people their developer account, and the rules are written specifically to catch it.

How do you ask a stranger to test something?

Every failed recruiting message fails the same way: it is long, it is about you, and the ask is unbounded. "Would you mind checking out my app and letting me know what you think" asks for an unknown amount of time to do an undefined job.

A message that works has four parts and fits in a phone screen:

1. Why them, specifically. One clause proving you read their post. "You mentioned reconciling invoices by hand every month."
2. What it is, in one line. No pitch. What it does, for whom.
3. A bounded ask with a number. "Twenty minutes this week" or "one task, about five minutes". Bounded asks get answered.
4. An out. "Totally fine if not" costs you nothing and raises replies, because it removes the social cost of ignoring you.

Here it is assembled, for rung four:

Hi Dana, you posted in the r/smallbusiness thread about reconciling invoices by hand every month. I built a tool that matches bank lines to invoices automatically and I am looking for five people to try it before I open it up. It would be about twenty minutes, this week, and I would want to watch you use it rather than send you a survey. No cost, nothing to install. Completely fine if you would rather not.

For rung one, cut it in half, because the relationship is already there:

Hey, you said back in March to ping you when this was working. It is working. Fifteen minutes this week? I mostly want to watch where you get stuck.

Three rules underneath all of that. Never open with a link. Never ask a group when you can ask a person. And never DM someone in a community whose rules do not allow DMs, which most do not: Discord's own community guidelines treat unsolicited bulk messaging as spam, and the community you did it in will notice faster than Discord does.

How many testers do you actually need?

Fewer than the number in your head.

For finding out what is broken, Nielsen Norman Group's research on testing with five users puts the average share of usability problems surfaced by a single test user at about 31 percent, which is why their guidance is small batches: run five, fix what you found, run five more. Twenty people looking at the same broken onboarding all report the same broken onboarding, and you have spent four times the recruiting effort for one finding.

For platform requirements, the numbers are set for you and are not negotiable. Google Play requires personal developer accounts created after 13 November 2023 to run a closed test with at least 12 testers opted in continuously for 14 days before applying for production access. That is a compliance number, not a research number, and the two goals need different handling: twelve opted-in accounts satisfy Google, five engaged humans teach you something.

A workable shape for a solo build:

• Round one: 3 to 5 people, watched live if at all possible. Goal: find the thing that stops people cold.
• Round two: another 5, after fixes. Goal: confirm the stopper is gone and find the next one.
• Round three: open the public surfaces. Goal: volume, edge cases, devices you do not own.

Three rounds of five beats one round of thirty, every time, because the fixes happen in between.

What do you owe a tester in return?

Something, always, and it is rarely money.

• A reply within a day. Not a fix, a reply. Silence after someone spends twenty minutes on you is the fastest way to lose the second round.
• Visible follow-through. "You got stuck on the import screen, so I rebuilt it, here it is." That single message turns a tester into a repeat tester more reliably than any incentive.
• Credit, if they want it. Ask first. Some people love being listed as an early tester and some would rather not be associated with a beta.
• Free access to the thing, permanently, if it is small enough to give. Cheap for you, disproportionately valued by them.
• The trade, if that is how you got them. If someone tested yours on the promise you would test theirs, that promise outranks your roadmap this week.

What you do not owe them is agreement. Feedback is data, not instructions, and a solo maker who implements every request ships a product shaped like a committee. The filter for which feedback to act on is the whole point of the beta tester checklist.

When should you stop recruiting and start shipping?

Stop when new testers stop surprising you.

Concretely: when three consecutive sessions produce no finding you had not already written down, recruiting is no longer the constraint. Your build queue is. More testers at that point is procrastination with a productive-looking shape.

Two other stopping signals worth naming. If you are recruiting to feel like you are making progress rather than to answer a question, stop, because the question is what makes a session useful. And if every finding is already on your list and none of it is fixed, close the recruiting doc and go fix things. Testers who report an issue that is still there a month later do not come back for round three.

After that, the job changes from recruiting to distribution, which is a different discipline with a different playbook: how to get your first 100 people to try your app.

Frequently asked questions

How many beta testers is enough?

For learning, five per round, in rounds, with fixes in between. Nielsen Norman Group's model puts the average share of usability problems found by one test user at roughly 31 percent, so the fifth person in a batch is already mostly confirming what the first four told you. For platform compliance the number is whatever the platform says: Google Play's production access path requires 12 testers opted in for 14 continuous days. Hit that number for the store, and use small watched batches for the product.

Should I pay beta testers?

Generally no, with one exception. Paying converts a tester into a contractor, and contractors complete the task rather than telling you the task is pointless, which is the answer you actually need at this stage. The exception is when you need a specific demographic you cannot reach any other way, such as a device, a region, or a profession outside your network. Then a panel or a small honorarium is reasonable, as long as you understand you are buying usability findings and not demand signal. Never pay for installs, opt-ins, or ratings on app stores. That is a policy violation on both major stores and the penalty lands on the developer account.

Where do I find testers for a niche B2B app?

Rung four, almost exclusively. Generic maker communities cannot help you find someone who runs payroll for a dental practice. The people you want are in a professional forum, a trade association group, a LinkedIn group for that role, or the support community of the incumbent tool they already hate. Find the threads where they describe the problem, message the individuals, and expect a low reply rate and a very high value per reply. One practitioner who agrees to twenty minutes is worth more to a vertical product than a launch post that reaches thousands of the wrong people.

How long should a beta run?

As long as it takes to answer the question you opened it with, which for a small app is usually two to six weeks. Set an end date at the start and tell testers what it is, because an open-ended beta quietly becomes the product. If the platform imposes a window, that becomes your floor: Google's closed testing requirement means at least 14 consecutive days of opted-in testers before you can apply for production. End it with a short note to everyone who took part saying what changed because of them, which is also the cheapest way to keep them for the next round.

Put the beta somewhere people can find it

Every rung above is a conversation you have to start. A listing is the one thing that works while you sleep.

Submit your app free and it sits in the showcase with your link, your description and your screenshots, reviewed by a human before it goes live, at no cost. The requirement is that people can actually try it: free, freemium or a free trial, a working URL, a real product. There is a featured spot if you want position and a badge, and that is exactly what it is, a position and a badge, not a promise of traffic. Most makers should start with the free listing, and it is genuinely free.

Then go send five messages. Individually.