DEV Community: Can Dizdar

Where to find beta testers for your app (the free ways first)

Can Dizdar — Thu, 05 Nov 2026 22:28:34 +0000

A TestFlight link dropped in a group chat usually gets a few installs and almost no feedback. I run a paid testing service, so I'm biased, but most of what works is free, and it's worth trying in this order.

1. Start with people who already know you

Your email list, your Discord, the friends who actually fit your audience. They install because they like you, which is also the problem: they're kind, and they rarely tell you what's broken.

What helps is a small, specific ask. Not "let me know what you think", but "open the app, sign up, and try to log your first workout. Reply with the moment you got stuck." One task and a deadline gets you more replies than a long message.

2. On iOS, TestFlight does the distribution

TestFlight has two kinds of testers:

Internal testers are people on your App Store Connect team, up to 100.
External testers can be anyone, up to 10,000, by email invite or a public link.

Two things catch people out. The first build you send to external testers goes through Apple's beta app review, so do that a few days before you need the testers. And each build expires after 90 days, so an old link stops working.

The public link is the useful part. Put it wherever your audience already is, and you can recruit strangers without collecting their emails first.

3. On Android, use the Play Console tracks

Google Play gives you three testing tracks:

Internal testing: up to 100 testers, no review, the fastest way to get a build onto real phones.
Closed testing: testers join through an opt-in link, by email list or Google Group.
Open testing: anyone can join from the store listing.

If your developer account is a personal one created after 13 November 2023, there's a catch: you need a closed test with at least 12 testers opted in for 14 days in a row before you can publish to production. Plan for that early. It holds up a lot of the first launches I see.

Outside Play, Firebase App Distribution is the closest thing to TestFlight. You upload an APK or AAB and invite testers by email, but they have to install the Firebase App Tester app first, and some won't.

4. Communities and beta directories

Reddit testing communities, BetaList and BetaFamily are free to post in. They can work, especially if your app is interesting to other makers. Reply rates swing a lot, though, and testers who sign up for fun drift away after a day or two. Follow up personally with anyone who installs.

5. How many testers you actually need

Fewer than you think, for usability. Nielsen Norman Group's research found that about five people per type of user find most of the usability problems. Three rounds of five, with fixes in between, will teach you more than one round of fifteen.

You need more people for crashes on odd devices, and at least 12 for the Google Play rule above, plus a few spare in case someone drops out.

6. Ask them to record, not to summarize

The most useful thing a beta tester can give you is their screen and their voice while they use the app. A written summary tells you what they remember. A recording shows you the twelve seconds where they couldn't find the button.

We see this in our own numbers: across 664 completed sessions on TestFi, recorded sessions averaged 78 out of 100 on our quality score, against 50 for written ones. If a tester is willing, ask them to share a screen recording with you.

7. When paying for testers makes sense

When you need people on the build today, when you need strangers rather than friends, or when you want a recording from every tester without chasing anyone. That's what we built TestFi for: testers install your build on their own phones and record the session, $5.99 a recorded tester or $3.99 for a written report. I wrote up the free and paid options side by side here.

If you try the free routes first and they work, great. That's the cheapest feedback you'll ever get.

Where did your first beta testers come from? I'm curious what's worked for other people.

More testing required to access Google Play production? A 14-day plan before you reapply

Can Dizdar — Fri, 23 Oct 2026 16:50:54 +0000

Google refused your production access with an email titled "More testing required to access Google Play production". It lists two possible reasons, that testers weren't engaged with your app or that you didn't follow testing best practices, and asks you to test with closed testing "for an additional 14 days with real testers" before applying again. Your account is fine and nothing gets removed. So the real question is what to do with those 14 days.

This is the plan I'd follow. I run TestFi, a closed testing service, so I read a lot of these emails. Google doesn't say how it scores engagement, so treat this as a plan built around what the production form asks, not a formula.

Day 0: work out which reason it is

There are two. Fewer than 12 opted-in testers is a count, and Play Console shows it to you. Insufficient engagement is a judgment about what your testers did. They need different fixes:

Below 12: recruit back up. Each tester needs 14 days in a row, so in practice the clock starts again from the day you're back at 12.
Engagement or "best practices": keep the testers you have if they'll actually use the app, and change what you ask of them.

Either way, don't delete or pause the closed track. That throws away everyone who's still opted in.

Day 1: give testers tasks, not "try the app"

Write down three to five things a real user would do in their first week. For a made-up recipe app: save three recipes, build a shopping list from two of them, switch units to metric, cook one thing in step-by-step mode. Send the list with one place to reply, an email address or a form.

"Try the app and let me know" gets you nothing you can put on the form.

Days 2 to 6: keep a log

One row per tester per thing they did: date, who, what, what broke. A spreadsheet is plenty. You'll copy from it on day 14, because the form asks for exactly this: whether testers used all the features, whether their usage looked like real users, and a summary of the feedback and how you collected it.

Day 7: ask for a note, then ship a fix

Ask each tester what they did and what annoyed them. Pick one thing they reported and fix it. Push the build to the closed track and tell testers what changed, so they open the new version. An update doesn't reset anyone's days, since Google counts opt-ins, not versions.

That one update is the most direct answer to "testing best practices". The production readiness part of the form asks what you changed because of the closed test, and "version 1.0.3 fixed the crash two testers hit on Android 13" is an answer.

Days 8 to 13: a second round

Give the testers who went quiet one more task, ideally one that touches the fix. If someone has gone for good, don't worry about it unless you'd drop below 12.

Day 14: write the answers from the log

A weak answer to the engagement question: "Testers used the app and gave positive feedback." It's probably true, and it tells the reviewer nothing.

A stronger one, for the made-up recipe app: "11 of 14 testers saved at least three recipes in the first week. Most used the shopping list; only two tried unit conversion, which is what we expect from new users. Four testers said the screen turned off in the middle of step-by-step mode. Version 1.0.3 on day 8 keeps the screen awake in that mode, and three of those four cooked with it again after the update."

That one has counts, a problem, a version number and a date, and you can only write it if you logged things as they happened. Then apply. Google says the review usually takes 7 days or less.

If you need new testers

If your testers were swap partners who stopped opening the app, recruit people who will use it, and get more than 12 so a single dropout doesn't restart the clock. Across 112 closed tests we ran up to October 2026, reaching 12 confirmed installs took a median of 63.6 hours, so add about three days to the plan.

That part is what TestFi sells: 16 testers on your track for $39.99, a note from each one on day 7 and day 14, and draft answers for the production form written from those notes. If fewer than 12 are still opted in on day 14, the test runs again free, and the same goes if Google refuses you over engagement and fewer than 12 testers wrote notes that show real use. Nobody controls Google's decision, us included.

Still choosing a track? The previous post in this series covers internal vs closed vs open testing. The longer version of this one, with an FAQ, is on our blog.

Internal vs closed vs open testing on Google Play: which one counts for the 12-tester rule

Can Dizdar — Fri, 23 Oct 2026 10:40:53 +0000

If your personal Play developer account was created after 13 November 2023, only one of the three testing tracks gets you to production: closed testing. Internal testing doesn't count toward the 12 testers for 14 days, and open testing stays locked until you already have production access.

That's the short answer. The rest is the four mistakes I see most from developers who run closed tests through TestFi. It's my product, so weigh that, but each of these mistakes costs about a week whoever you test with.

The three tracks side by side

	Internal	Closed	Open
Who can join	People you add by email	Your email lists or a Google Group	Anyone who finds it on Google Play
How many	Up to 100 per app	Lists of up to 2,000 each, or Google Groups	Unlimited, or a cap of at least 1,000
Review first	Usually live in minutes	Normal app review	Normal app review
Counts for the 12-tester rule	No	Yes	No
On a new personal account	Available	Available, and required	Locked until production access

Mistake 1: running the 14 days on internal testing

Internal is the easy track. No review, and builds reach your phone in minutes. So people invite twelve friends there, wait two weeks, and then can't find an Apply for production button anywhere. Google only counts testers opted in to a closed track. Keep internal for yourself and your team, and put testers on closed.

Mistake 2: being on both tracks yourself

Someone who qualifies for more than one track gets the build with the highest version code. And anyone opted in to internal has to opt out before they can receive closed builds. If your own phone never shows the closed build, that's usually why: leave internal first. If your team should always get the newest build, number internal builds above closed ones.

Mistake 3: treating open testing as a shortcut

On a personal account created after 13 November 2023, open testing is locked until you have production access, and production access needs the closed test. You can't skip ahead. The order is internal while you build, closed to qualify, then production, and open testing after that if you still want a public beta. Older personal accounts and organization accounts can go straight to open.

Mistake 4: thinking day 14 is the finish line

There are two different reviews. Every build you push to a track goes through app review. Production access review happens once, after the closed test qualifies: you fill in a questionnaire in Play Console and Google decides whether the account can publish. Google says that usually takes 7 days or less.

Finishing the 14 days doesn't approve you on its own. The form asks what your testers did and what you changed because of them. I went through it question by question earlier in this series.

Updating the app during the test is fine, by the way. A new build goes through review again, but nobody's days reset, because Google counts opt-ins, not versions. A mid-test fix also gives you something real to write on that form.

How long the whole thing takes

Across 112 closed tests we ran up to October 2026, the median time to the 12th installed tester was 63.6 hours. Add the 14 days, a day or two of review at the start, and up to a week of production review at the end. Plan on about 17 days before you can apply.

The days count per tester. If your 12th person joins on day 3, your earliest application date moves back with them, and anyone who opts out and back in needs a new 14 days in a row. That's why paid services put more than 12 people on the track. TestFi puts 16 on yours for $39.99, with notes from each tester on day 7 and day 14.

The longer version, with paid apps, Google Groups and an FAQ, is in our internal vs closed vs open testing guide.

What makes a Google Play closed test slow? Data from 85 closed tests

Can Dizdar — Sat, 17 Oct 2026 16:14:46 +0000

When a Google Play closed test drags, the natural thing is to blame the testers. Our numbers say it's mostly something else.

I run TestFi, which fills closed tests for developers on new personal Play accounts. Testers usually take all the seats within a couple of hours. Then each one goes through two hand-offs before they count: the developer adds their Gmail to the testers list in Play Console, and the tester installs from the opt-in link.

The numbers

I took the 85 closed tests that ran on TestFi in August and September 2026 and reached 12 confirmed installs, and split them by how long that took after the test went live. We count an install once we've checked the tester's proof.

Time to 12 installs	Tests	Median time for the developer to add a tester's Gmail	Median time from added to installed
3 days or less	42	3.7 hours	16.0 hours
3 to 7 days	21	19.2 hours	19.4 hours
More than 7 days	22	24.7 hours	20.1 hours

The install step hardly moves: testers took 16 to 20 hours whether the test was fast or slow. The difference sits in the first hand-off. In the fast tests, a tester's Gmail went onto the list in under four hours. In the slow ones it took a day, and that day comes back for every tester who arrives late.

The fix is boring. If you use an email list, check it twice a day and add people as they show up, not in one batch at the weekend. Or put a Google Group on the track: testers join the group themselves and the hand-off disappears.

Things that stop testers installing at all

Speed is one problem. A few setups block installs completely. Check these before you share the link:

The link. The store listing link (it has /store/apps/details in it) doesn't let anyone join a test. Testers need the opt-in link from your closed testing track, the one with /apps/testing/.
The release. If the build is still in review, or was never rolled out to the closed track, testers have nothing to install.
Paid apps. Google Play charges everyone who installs a paid app, closed-test testers included. Make a promo code for each tester and send it with the link.
Countries. If the track is limited to some countries, testers outside them can't install. Leave it open unless the app really doesn't work elsewhere.
The Google account on the phone. Testers have to install with the exact Gmail you added. Anyone with two accounts on one phone runs into this.
Device compatibility. A high minimum SDK or a device exclusion in the catalog quietly blocks some phones.

Before you share the link

Opt-in link, not the store link.
Release approved and rolled out to the closed track.
Promo codes ready if the app costs money.
Countries open.
Someone checking the testers list twice a day, or a Google Group on the track.

None of this makes Google's 14 days shorter. It shortens everything around them, which is usually what turns a three-week job into five.

Disclosure: I'm the founder of TestFi. Our closed test puts 16 testers on your track for $39.99, or 20 for $49.99, and the campaign page lists each tester's Gmail as they arrive so you can paste it into Play Console straight away. Our public numbers are on the closed testing data page.

Hit something that isn't on this list? Tell me in the comments.

Google Play's production access form, question by question (what to write after your 14-day closed test)

Can Dizdar — Sat, 17 Oct 2026 16:13:27 +0000

Getting 12 testers through 14 days is the part everyone talks about. After that, Play Console hands you a form, and the form is where a lot of apps get turned back.

I run TestFi, a small testing marketplace, and developers forward us their refusal emails. The reason is almost never that they had too few testers. It's that Google didn't see enough engagement, or didn't see the developer do anything with what testers said. Both get judged from what you write in this form.

Google doesn't publish the form, and the wording shifts a little between accounts. This is how it reads in Play Console in 2026. There are three sections.

About your closed test

1. How did you recruit users for your closed test? For example, did you ask friends and family, or use a paid testing provider?

Tell the truth, including if you paid a testing service. Paid testers aren't against the rules. Fake accounts, emulators and one person running five accounts are. A vague answer reads worse than an honest one.

Weak: "Friends and online communities."

Better: "16 testers through [service], a paid testing provider, plus 3 colleagues. Everyone installed from the opt-in link on their own Android phone."

2. How easy was it to recruit testers for your app?

Multiple choice. Pick what happened. Nobody gets refused for saying it was hard.

3. Describe the engagement you received from testers.

This is the one the refusals point at. Numbers beat adjectives: how many testers stayed the full 14 days, how often they came back, what they actually did in the app. If you asked for check-ins, say how many came back.

Weak: "Testers were very engaged and used the app every day."

Better (the app here is made up, use your own numbers): "14 of 16 testers stayed opted in for all 14 days. 13 sent a written check-in on day 7 and 12 on day 14. Most used the habit list and reminders. 5 tried CSV export, which is how we found the export crash."

4. Provide a summary of the feedback that you received from testers. Include how you collected the feedback.

Two answers in one. How: a form, check-in questions, an email thread, a feedback button in the app. What: group it into themes and count them. "Six testers said onboarding asked for too much before showing anything" is a summary. "Testers liked the app" isn't.

About your app

5. Who is the intended audience for your app?

One or two specific sentences. "Students revising for exams who want five-minute daily reviews" beats "everyone who wants to learn".

6. Describe how your app provides value to the users.

What someone can do with it that they couldn't before, in plain words. Not a feature list.

7. How many installs do you expect in your first year?

Multiple choice. Be realistic. A small number is not a red flag.

Your production readiness

8. What changes did you make based on your closed test?

The other refusal reason I see a lot: testers said things and nothing changed. List the updates you shipped during or after the test, each one tied to something a tester said, with version numbers.

Weak: "We fixed some bugs and improved the UI."

Better: "1.0.3 fixed the CSV export crash two testers reported. 1.0.4 cut onboarding from five screens to two after six testers called it too long."

9. How did you decide that your app is ready for production?

Your evidence. What testers found and you fixed, what's still open and why it can wait, testers getting through the main flow on the last build.

Collect the material during the 14 days, not after

Nearly every weak answer I've read has the same cause: the developer opened the form on day 15 with nothing written down.

Give testers a small task every few days, so they have something specific to report.
Ask for a written check-in on day 7 and day 14 at least, and keep them.
Ship one update during the test that answers something a tester said.
Write down version numbers and dates as you go.

Already refused? You can run another closed test and apply again. Do those four things the second time and write the answers from what you collected.

Disclosure: I'm the founder of TestFi. Our closed test is $39.99 for 16 testers, or $49.99 for 20. Every tester writes check-in notes on day 7 and day 14, and the campaign dashboard drafts answers to this form from those notes, leaving brackets for the parts only you know, like what you changed. Details at testfi.app/google-play-12-testers. The advice above works however you find your testers.

If your refusal email says something I didn't cover, paste the reason in the comments and I'll tell you what I'd write.

How to get 12 testers for Google Play closed testing (with numbers from 112 closed tests)

Can Dizdar — Thu, 15 Oct 2026 23:06:19 +0000

If you opened a personal Google Play developer account after November 13, 2023, you can't publish to production until you've run a closed test with at least 12 testers who stay opted in for 14 days in a row. Then you apply for production access and Google reviews it.

I run TestFi, a small testing marketplace, and a lot of what we do now is exactly this. Since May we've run more than a hundred of these closed tests for other developers. This is what I'd tell a friend who just hit the "Your app requires more testing to access Google Play production" screen.

The rule, in plain words
At least 12 testers, opted in to a closed testing track.
14 consecutive days, counted per tester.
After that you apply for production access. The application asks about your closed test, and Google says the review usually takes 7 days or less.
It applies to personal accounts only. Organization accounts don't have it.

Does the 14-day clock reset if a tester drops out?
For that seat, yes. Google counts the 14 days per tester. If someone leaves on day 10 and you replace them on day 11, the new person starts their own 14 days, and you can't apply until 12 people have each done 14. One drop-out late in the test can push your date out by almost two weeks.

That's the whole reason to recruit more than 12. We put 16 on every run. Four spare seats sounds like a lot until you've watched someone uninstall on day 12.

Where to find 12 testers
Friends and family
Free. The hard part isn't getting 12 people to install, it's getting 12 people to keep the app for two weeks and open it more than once. It works if you have a group chat that owes you a favor.

Swap communities
Developers test each other's apps, through Reddit threads, Discord servers or apps built around swapping. Free in money, expensive in time: you test their apps too, and people tend to drift off once their own test is done.

Fiverr gigs
The cheapest paid route, often $5 to $15 to start. What the listing doesn't tell you is whether the testers are distinct real people on real phones, whether they stay for all 14 days, and whether they'll use the app enough to give you something to write in the application. Ask before you order.

Closed testing services
As of October 2026 they run from about $15 to $40 per app for 12 to 25 testers, and most offer a refund or a re-run if Google says no. Read the guarantee's conditions, and check whether the testers are real people or other developers in a swap.

How long does it take?
Getting the testers is the fast part, though not instant. In our public numbers (112 closed tests up to 1 October 2026), the median time from publishing a test to the 12th confirmed install was 63.6 hours, a little under three days. Twelve testers claim the seats within about two hours. The rest is two hand-offs per tester: the developer adds their Gmail to the Play Console list (median 8 hours), then the tester installs (median 19 hours). If you add testers the moment they sign up, you take a day off your own timeline.

Then the 14 days start, and then Google's review. So from "I need testers" to "approved", plan on roughly three to four weeks, not two.

Why Google refuses production access over "engagement"
The production access application asks how you recruited testers, how engaged they were, what feedback they gave, and what you changed because of it. A refusal over engagement usually means one of two things: testers installed the app and barely opened it, or the answers were vague.

What helps:

Give testers something specific to do every few days ("create an account", "try the export", "use it once on day 7"), not just "install it".
Collect their feedback in writing during the test, so you have real material to summarize later.
Ship at least one update during the 14 days that responds to something a tester said, and mention it in the application.
Answer with specifics: how many testers, what they used, a short quote or two, what you fixed.
If you got refused, you can run another closed test and apply again. Do the four things above the second time.

Is it allowed to pay testers?
Google's requirement sets the number of testers and the 14 days. It doesn't say where testers have to come from, and paid testing services and freelancers are common. What matters is that they're distinct real people using the app on their own phones. Fake accounts, emulators and one person running several accounts are the things to stay away from.

What I'd do
Start the closed test as soon as the build is stable, not the week you want to launch.
Recruit 15 or 16 people, not 12.
Give them a small task every few days and keep their notes.
Push one update during the test.
Write the production access answers from those notes, with numbers.
Disclosure, since you're reading this on a post by the founder of a testing service: TestFi's closed test is $39.99 for 16 real testers, each one leaves notes on day 7 and day 14, and if fewer than 12 are still there on day 14 we run it again for free. Details are at testfi.app/google-play-12-testers. The steps above work whatever you end up using.

If you're stuck on something specific, ask in the comments. I'll answer.

Google Play 12 Testers for 14 Days: The Complete Guide (2026)

Can Dizdar — Fri, 17 Jul 2026 10:38:02 +0000

If you created a personal Google Play developer account after November 13, 2023, you cannot publish your app until you run a closed test with at least 12 testers opted in for 14 continuous days. This guide covers the Play Console setup, the mistakes that quietly reset your 14-day clock, and the real ways to find testers.

What Google actually requires

You need at least 12 testers opted in to your closed test, continuously for the last 14 days, before you can apply for production access. Twelve invites sent is not twelve testers. It means twelve unique Google accounts that opted in through your link and installed the app on a real device. Emulators, bots, and duplicate accounts do not count.

Organization accounts are exempt. Google dropped the minimum from 20 testers to 12 on December 11, 2024, but kept the 14-day window.

Only the closed track counts. Internal testing and open testing don't, and this comparison of internal, closed and open testing covers what each one is for.

Setting up closed testing in Play Console, step by step

In Play Console, open your app and go to Test and release, then Testing, then Closed testing. Create a new closed test track.
Upload a build to the track. Any installable version is enough to start.
Add testers under the track's Testers tab: paste Gmail addresses or link a Google Group.
Send testers the opt-in link Play Console generates. Each person must open it signed into their Google account, tap Join, then install from the Play Store.
The 14-day clock starts once the track is live and at least 12 testers have opted in. It counts from the moment you cross 12.
After 14 unbroken days at 12 or more testers, an Apply for production button appears on your dashboard.
Google reviews the application, usually within 7 days.

The part that catches most developers: the clock resets

The 14 days must be consecutive. If a tester opts out on day 9, their days are gone; opting back in restarts them from zero. If you drop below 12 testers total, your whole window breaks. This is why recruiting friends fails so often: people uninstall, switch phones, or forget, and one dropout on day 13 pushes your launch back two weeks.

The real goal is not 12 testers. It is 12 testers who will not leave.

How long getting to 12 takes

I run a testing service (more on that below), so I have numbers. Across 112 closed tests up to October 2026, the median time to the 12th installed tester was 63.6 hours, about two and a half days. It isn't always that quick: 19 tests took more than a week. The full breakdown by month is public.

So budget three days to fill the track, then the 14 days, then up to a week of review.

Ways to find your 12 testers

Friends and family. Free, unreliable. Works only if you can personally nag 15+ people daily.
Swap groups on Telegram/Discord/forums. Free, slow, and feedback quality is near zero because everyone is farming opt-ins.
Fiverr gigs. $5 to $50 for testers who opt in and vanish. Some use account patterns that look like testing farms to Google.
A paid testing service. This is what I built TestFi for. $39.99 puts 16 real testers on your closed track, so a couple of dropouts don't sink you, and if fewer than 12 are still opted in on day 14 the re-run is free. Each tester also sends written notes on day 7 and day 14, which is the kind of evidence Google's production form asks about.

Full disclosure: TestFi is my product. The prices are public and you can check everything without talking to anyone.

FAQ

When does the 14-day clock start? Once your track is live with a build and 12+ testers have opted in. Not when you create the track.

Do testers need to open the app every day? The written rule is staying opted in for 14 continuous days. But Google's review also asks about engagement, and apps whose testers never opened them get rejected for insufficient testing.

What happens if a tester opts out? Their continuous-day count dies. Below 12 total, your window breaks and restarts.

How long does the production review take? Usually within 7 days. Budget about three weeks end to end.

Updated October 2026 with current prices and data. Originally published on the TestFi blog.