Do You Need 12 New Testers for Every Play App?

Each app needs its own closed test. Google's requirement is written in per-app terms: personal accounts created after 13 November 2023 must run a closed test for their app, and at least 12 testers must be opted in to your closed test when you apply for production access. Production access itself is applied for per app, from that app's Dashboard.

What that means in practice: shipping a second app restarts the process. Fourteen more continuous days, twelve more opted-in testers, and a second production access application.

What it does not mean is that you need twelve new people. Testers can help with as many of your apps as you like. They simply have to opt in to each app's closed test individually, because the opt-in is tied to the app's testing program rather than to a relationship with you.

Why the requirement is per app

An obvious question follows from the per-app reading: why can't one cohort of twelve cover everything you publish?

The answer is in what the requirement is measuring. The production access application asks about your closed test — how you tested, what feedback you received, what you did with it. That is app-specific evidence. A tester who opted in to app A has produced no evidence about app B, and a reviewer looking at app B's application has nothing to evaluate.

So the unit of the requirement is the unit of the evidence: one app, one test, one feedback set, one application.

What repeats per app

Reusing the same testers across apps

You can, and serial publishers should. The mechanics are simple:

1. The tester is already a known, verified Android user.
2. For the new app, they join that app's closed test by opening its opt-in link and opting in.
3. Their opt-in for the new app starts at that moment, not at any earlier date.
4. Your 14 continuous days for the new app begin once 12 or more are opted in and the count holds.

Three practical notes from running these windows repeatedly.

• Reuse is efficient but not free. You still need twelve opted-in testers on the new app's track for fourteen continuous days. The saving is sourcing time, not the window.
• Do not assume an opt-in carried over. The opt-in is per app. A tester who helped with your last launch has not opted in to this one until they tap the link.
• Buffer twice over. Reused testers are more likely to go through the motions the second time. Recruit 15-16 again rather than assuming experienced testers will be as attentive.

This is why agencies and serial indie publishers tend to keep a standing pool rather than recruiting per launch. The pool removes the sourcing problem; it does not remove the window.

What happens with updates to an app that is already live

Here is where we have to be careful about the difference between what Google publishes and what we infer.

What Google publishes: the testing requirement is about new personal developer accounts and apps that are not yet eligible for distribution on Google Play. Meeting it lets you apply for production access. Once approved, you can access the Production track and distribute your app.

What we infer: the requirement is framed as a gate on reaching production for the first time, so an app that is already in production should not need to repeat the 12-tester, 14-day window to ship an update. We are labelling that as our inference rather than policy text, because Google's Help Center article is written around the path to production rather than around post-launch update flows.

If you are in that situation and it matters commercially, the right move is to check the current Play Console state for your app and, if it is unclear, contact Play support. Do not take a blog's inference — including ours — as policy.

What this means for publishers with several apps

Running two windows concurrently means two cohorts of 15-16 opted-in testers, which is a real coordination load. Running them sequentially is slower but considerably easier to hold, and a count that dips below 12 costs you more than the sequencing saved.

Planning a second launch

1. Assume a full window. Fourteen continuous days, twelve opted in, per app. Do not plan around an exemption that is not published.
2. Approach your existing testers first. They are known quantities and they already have the app-install habit.
3. Re-recruit to 15-16, not 12. The buffer matters on repeat runs too.
4. Send the new app's opt-in link explicitly. Say the words "you need to opt in again" — most people will assume their previous opt-in still counts.
5. Check the opted-in count daily for the new app, exactly as you did the first time.
6. Keep separate feedback notes per app. The second application needs its own testing summary, and reusing the first one will not describe the right test.

Across OnTesters' own campaign data, the pattern that separates campaigns is the same on a first launch and a fifth: testers dropping below the minimum accounts for roughly 40% of the rejections we see, and engagement correlates strongly with outcomes — 97% success correlation where testers were active on 10 or more days, against 41% for 5-7 active days. Our figures, from 1,500+ analyzed campaigns.

Why a second app is not a second formality

Developers who have been through the process once tend to assume the second time is faster. It is, but not because the requirement changes — because you know what you are doing. The two weeks are still two weeks.

The most common repeat-launch mistake is assuming experience replaces the mechanics. A developer who ran a clean first window will often announce a second app to their tester pool, receive a wave of "done" replies, and discover on day three that the opted-in count for the new app is four. The people are reusable; the opt-in is not — and the rules that make one person count as a tester, per app, are in What Counts as a Google Play Closed Tester.

Running a second window without the first one's problems

1. Budget the full window in your release calendar. Fourteen days plus recruitment plus review, per app. Two apps published close together means two overlapping windows or two sequential ones.
2. Ask your existing testers first, then top up with new ones. Reuse saves sourcing time and costs nothing in compliance, but do not assume experienced testers will be as attentive — mix in new sources.
3. Send the new app's opt-in link with an explicit note that the previous opt-in does not transfer. Most people will reasonably assume it does.
4. Check the new app's count daily, separately from any other app you are running. One app's healthy count tells you nothing about another's.
5. Write a fresh feedback summary. Application two needs a summary of app two's test.

That fourth point is where portfolios get into trouble. If you are running two windows concurrently you have two opted-in counts to verify every day, and it is easy to check the one you are worried about and assume the other is fine. Running windows sequentially is slower and considerably easier to hold.

What this means for agencies and serial publishers

The economics of repeat publishing change with volume, and they point toward a standing pool rather than per-launch recruitment.

• Keep a named list of testers who held for a full window. They are the only asset that compounds across launches.
• Standardise the briefing. One message you reuse, updated with the app name and dates, removes the main source of variation between launches.
• Standardise the feedback capture. Same channel, same format, every app, so the summary writes itself.
• Plan the calendar around windows, not releases. A launch date is really a window start date minus about three weeks.

The alternative is buying testers per launch, which trades money for the sourcing and replacement work and is a legitimate choice for an agency billing on delivery. Either way, the per-app nature of the requirement is what drives the planning, and the tester-reuse mechanics specifically are in Can the Same 12 Testers Cover Multiple Play Apps?

The cost of getting this wrong on a portfolio

For a publisher with several apps, a per-app misunderstanding compounds rather than stays constant. Three apps means three windows, three cohorts, three feedback summaries and three reviews — and a mistake made once is a mistake made repeatedly.

The most expensive version is planning a simultaneous multi-app launch. Two concurrent windows mean holding 30-32 opted-in testers across two tracks, two daily counts to verify, and two applications to write. That is achievable with a managed pool and genuinely unpleasant by hand, and a dip in one app will distract you from the other at exactly the moment it matters.

Sequencing is slower on paper and usually faster in practice, because a window that holds is worth more than two that overlap badly. If your calendar forces concurrency, at minimum stagger the start dates by a few days so the two windows are not at their riskiest points in the same week. The per-app rule itself is set out in Do You Need 12 New Testers for Every Play App?

Frequently Asked Questions

Do I need 12 testers for every app I publish?

Yes, for personal developer accounts created on or after 13 November 2023. Google's requirement is written per app, and production access is applied for per app. Each app needs its own closed test with 12 testers opted in continuously for 14 days.

Can I use the same testers for my next app?

Yes. The people can be reused as often as you like. What repeats is the opt-in — they have to join the new app's closed test individually, and their opt-in for that app starts when they do.

Does my open testing track count toward a second app?

No. Open testing becomes available after you gain production access and is not the qualifying track. The requirement is a closed test.

Do I need to repeat device verification for each app?

Device verification is an account-level requirement rather than a per-app one. Check your Play Console Home page to confirm it is complete.

Do I need to redo the closed test to update an app that is already live?

Google's Help Center is written around the path to first production access. Our reading is that an app already in production does not need to repeat the 12-tester, 14-day window to ship an update — but that is an inference, not policy text. Verify in Play Console or contact Play support if it affects your plans.

Sources

Google Play Console Help — App testing requirements for new personal developer accounts (per-app framing of the requirement, production access application process, review timing). Google Play Console Help — Set up an open, closed, or internal test (per-app track setup, opt-in mechanics). External commentary: PrimeTestLab and Testers Community both treat the requirement as per-app; these are third-party sources, not Google policy. Inferences in this article are labelled. OnTesters campaign figures are our own.