← All writing

Getting a new app through Google Play’s closed testing requirement

Twelve people, fourteen days, and a test that has to mean something.

Google PlayAndroidPublishing
A cut-paper smartphone standing among twelve small coral pennant flags, beside a paper desk calendar with its day squares punched out.
Twelve testers and a fortnight of use, before production.

If you open a new personal developer account on Google Play today, you can upload a build, fill in a store listing and set up testing, but the Production track stays locked. Before Google will let a new personal account publish to everyone, the app has to go through a closed test with real people for two weeks, and then you apply for production access. This guide covers what the requirement is, how to set the test up, what the application asks, and the reasons Google gives for sending developers back for more testing. Every rule here comes from Google’s Play Console Help pages, checked on 29 October 2026.

In short

  • Personal accounts created after 13 November 2023 need at least 12 testers opted in to a closed test for at least 14 consecutive days.
  • The production application asks how the test went, who the app is for and what you changed, so a test nobody used makes a weak application.
  • Too few engaged testers, crashes, missing test logins and policy problems are the common reasons for being asked to keep testing.

Who the requirement applies to

The rule applies to personal developer accounts created after 13 November 2023. Google’s help page says those developers must test their apps before they can distribute them on Google Play, and that the Production and Pre-registration features in Play Console stay disabled until the requirement is met.

Personal accounts carry a few other steps too. Google’s getting-started page says the account owner must verify access to an Android device using the Play Console mobile app before publishing, and every new account goes through identity verification and a one-time registration fee of US$25. The testing requirement is described in terms of the app you want to publish, so plan for it with each new app rather than treating it as a one-off hurdle for the account.

If you’ve read guides that mention 20 testers, check the date. The current help page asks for 12.

The rules at a glance

  • 12 testers opted in to a closed test
  • 14 consecutive days of testing
  • US$25 one-time registration fee
  • 7 days or less, Google’s usual review time

What “12 testers for 14 days” actually means

The exact wording is that you need at least 12 testers “who have been opted in continuously for at least 14 days”. Three details in that sentence catch people out.

  • The days have to be consecutive. A tester who opts out and opts back in starts again, as far as the count is concerned.
  • Testers who leave before the 14 days are up don’t count at all.
  • The testers have to still be opted in when you apply. Twelve people who tested for two weeks and then left the programme won’t satisfy the rule on the day you press the button.

Recruit a margin

Recruit more than 12 people, so that one or two dropping out doesn’t reset your calendar, and tell every tester up front that they need to stay in the programme for at least two weeks. Google’s own tips say the same thing.

Setting up the closed test

Closed testing is its own track in Play Console. You choose who can join by adding email lists or Google Groups. With an email list, you type in the addresses of the Google accounts your testers use on their phones. With a Google Group, only members of the group can join, so testers have to join the group first.

Once the release on the closed track is published, Play Console shows an opt-in link. Each tester opens it, accepts the invitation and then installs the app from Google Play as normal. The link only appears after the track’s release is published, so don’t promise testers a link before you’ve rolled out the first build.

Testers can send you private feedback through Google Play during a closed test, but they can’t leave public reviews on a test version. Google recommends giving testers another channel as well, such as an email address. A short form or a shared document works too. What matters is that feedback lands somewhere you can read, sort and quote later, because the production application will ask for a summary of it.

The closed track also needs the same paperwork as a public release. The Data safety form, for example, has to be completed for apps on closed, open and production tracks. Filling in the store privacy disclosures covers that form in detail.

Finding twelve testers who will use the app

The production application asks whether testers used all of the app’s features and whether their usage matched how you expect real users to behave. Twelve people who install the app on day one and never open it again won’t give you good answers to either question, and Google lists “insufficient tester engagement” as a reason to require more testing.

Google’s advice is to recruit a diverse group that matches your target audience. In practice that means people who would plausibly use the app anyway. A budgeting app wants people who track money. A puzzle game wants people who play puzzle games on their commute. Friends and colleagues are fine if they fit, and they’re often the easiest people to keep opted in for two weeks.

Give them something to do. A short note at the start of each week, listing two or three things to try, turns a passive install into a real test. Ship updates during the fortnight as you fix what they find, and tell them what changed, so they have a reason to open the app again.

What the production application asks

When the requirement is met, you apply from the Dashboard in Play Console by choosing “Apply for production”. The application has three sections.

About your closed test

You’re asked how easy it was to recruit testers, whether testers used all of the app’s features, whether their usage matched what you expect in production and how it differed, and for a summary of the feedback you received and how you collected it.

About your app or game

You describe the target audience as specifically as you can, the app’s value to users (for a game, what makes it unique) and how many installs you expect in the first year.

About your production readiness

You explain what you changed because of the closed test and how you decided the app was ready for production.

None of these questions has a trick answer. They reward specifics. “Testers found the onboarding confusing, so we cut it from four screens to two” is a better answer than “we fixed bugs”. Keep a simple log during the test, with the date, the tester’s point and what you did about it, and the application mostly writes itself.

Why Google asks for more testing

The help page names the main reasons an application doesn’t go straight through.

  • Too few testers, or testers who didn’t engage. Fewer than 12 opted-in testers, or low engagement, can lead to a request for continued testing.
  • Policy problems. Google is explicit that the review “is not a troubleshooting step”. It expects you to check policy compliance yourself before applying.
  • Common problem areas. The page lists app content and features, app targeting and content rating, functional reliability such as crashes or missing screens, and missing test credentials for apps that need a login.

Give reviewers a way in

The last point is easy to miss. If your app has a sign-in screen, reviewers need a working account to get past it. The pre-launch report settings in Play Console have a place for test-account credentials, and Google recommends using a dedicated test account rather than a real one.

Run a pre-launch report before you apply. It runs automatically when you upload an app bundle, subject to device availability, and tests your app on real devices running Android 9 and above for stability, compatibility, performance and accessibility issues. A crash on a common phone is far cheaper to find there than in a reviewer’s notes.

Google says review usually takes seven days or less.

A fortnight that’s worth something

The requirement can feel like a tax on solo developers, and two weeks is a long time when a build is ready. The way to get value out of it is to treat the closed test as the first real launch rather than a waiting room.

  1. Before day one, have a stable build, a draft store listing and the Data safety form done.
  2. In the first week, invite more than 12 people, watch for crashes and push fixes quickly.
  3. In the second week, ask testers about specific features and about anything that confused them.
  4. On day fifteen, apply with a log of real feedback and real changes.

Putting an app in front of people earlier than feels comfortable is usually the right call, and the closed testing rule forces it. I’ve written more about finishing in what shipping small products keeps teaching me. If the app is a game, it’s also a good moment to check the basics in accessibility for small mobile games while testers are still around to tell you what they struggle with.

Sources & further reading

Another question worth following?

Explore the workGet in touch

A good project often starts here.

Leave me
a what if.

All the places to find me ↗
To Satyajit

There’s an app I wish existed.

Tell me who would use it and what they are trying to do. A rough sketch is plenty to start with.

Talk to me on LinkedInLet’s follow the question.