Since November 2023, Google Play has required new personal developer accounts to show that an app has been tested by real people before it can be released. The rule is simple to state and easy to fail: at least 12 testers, opted in to a closed test for 14 continuous days, followed by an application for production access that Google reviews and can refuse. This is how the requirement works in practice and how to run a test that passes the first time.
Who the rule applies to
| Account | Closed test required before production? |
|---|---|
| Personal account created after 13 November 2023 | Yes, for each app you want to release to production |
| Personal account created on or before 13 November 2023 | No |
| Organisation account | No |
The requirement started at 20 testers in November 2023 and was reduced to 12 on 11 December 2024. The 14-day period has not changed. If you are publishing for a business, the simplest way to avoid the rule is to publish from an organisation account in the business's name, which is the right account for a business app anyway; the set-up is covered in how to publish on Google Play in 2026.
How the 14-day clock really works
Google's own wording is precise: at least 12 testers must be opted in to your closed test when you apply for production access, and they must have been opted in continuously for the preceding 14 days. Three consequences follow:
- Invited is not opted in. A tester counts only after accepting the invitation through the test's opt-in link while signed in with the Google account on your list. Sending an email is not enough; check the count in Play Console.
- Continuity matters. A tester who leaves the test and rejoins starts a new continuous period. If your count dips below 12 during the fortnight, you do not have 12 testers with 14 continuous days on the day you apply.
- Plan a margin. Recruit 15 to 20 testers, so that a few who drop out do not reset your timetable.
What the production access application asks
Once the criteria are met, you apply from the Play Console dashboard. The form has three parts:
- About your closed test: how easy it was to recruit testers, how they engaged with the app, and a summary of the feedback you received.
- About your app: the intended audience, what value the app provides, and how many installs you expect in the first year.
- About your production readiness: what you changed as a result of testing, and how you decided the app is ready.
Google says review usually takes seven days or less but can take longer. Add that week to your launch plan: with the 14-day test, the minimum from first closed build to production is about three weeks.
Why applications are refused
When an application fails, Google asks you to continue testing. The stated reasons are fewer than 12 opted-in testers or insufficient tester engagement. In practice, insufficient engagement usually looks like one of these:
- Testers who installed the app once and never opened it again
- No feedback, or feedback that is generic ("nice app") and leads to no changes
- No new builds during the test, so there is no evidence that testing influenced the product
- Application answers that are vague, copied or inconsistent with what the testing shows
- An app that is visibly unfinished: placeholder screens, broken flows, crashes
A test plan that passes
| When | What to do |
|---|---|
| Before day 0 | Recruit 15–20 real people from your target audience: customers, staff, a waiting list. Collect the Google account each will use. |
| Day 0 | Upload a complete build to the closed testing track, add the testers (a mailing list or a group works well), and send the opt-in link with installation instructions. |
| Days 1–3 | Confirm every tester has opted in and installed. Send a short test script covering the app's core flows. |
| Days 4–10 | Collect feedback in one place, fix the real issues, and ship at least one or two updates with clear release notes. |
| Days 11–14 | Ask testers to repeat the core flows on the latest build; record what changed and why. |
| Day 14 or later | Confirm at least 12 testers show 14 continuous days, then apply, answering from your feedback log rather than from memory. |
The feedback log is the most useful document you will produce. It turns the application's questions into facts: who tested, what they found and what you changed. The same discipline belongs in any release, as we described in acceptance testing and sign-off.
A word on paid tester services
Services that sell groups of testers exist and are widely advertised. The requirement is about genuine testing, and applications whose testers show little engagement, and whose answers show no feedback-driven changes, are exactly the ones refused for more testing. Testers who uninstall or leave the group also break the continuity the rule measures. If you use outside help, use it to reach real users of your kind of app, and still run the test plan above.
After production access
Production access applies to the app that passed. A new app in the same personal account goes through its own closed test. Updates to an app that already has production access do not repeat the requirement, but they do go through normal review and must meet the current technical rules, including the Android 16 target API requirement for updates since 31 August 2026 and app registration for Android developer verification.
Frequently asked questions
Can the testers be my own team?
They can be part of it, but a test run only by colleagues rarely produces the engagement and feedback the application asks about. Mix in real target users.
Can I use internal testing instead?
No. The requirement refers to a closed test. Internal testing is still useful for your own team before the closed test starts.
Does switching to an organisation account help?
Organisation accounts are not subject to the requirement. For a business app that is the right account type in any case, but it needs a D-U-N-S number and organisation verification, which take time of their own.
Related Manboo Services
- Android App Development, including Play Console set-up, release tracks and policy declarations.
- iOS App Development, including App Store Connect, TestFlight and App Review preparation.
- Flutter App Development when one codebase must pass both stores' reviews.
- Software Maintenance for existing apps that need target API, SDK or policy updates.
- Request a scope review and estimate for a store launch or a rejected submission.