Google Play's 12 testers for 14 days, survived

By Abdalla Kamesh · Updated September 25, 2026 · Published September 14, 2026 · 5 min read

This is the requirement that turns “the app is finished” into “the app launches in three weeks,” and almost nobody discovers it until they try to publish.

The requirement

If your Google Play developer account is a personal account created after 13 November 2023, Google requires you to run a closed test with at least 12 testers who have opted in, sustained for 14 continuous days, before you may apply for production access.

Three words in that sentence do the work:

Opted in. A tester must accept the invitation and join the test. Being on your email list is not opting in.
Continuous. Fourteen consecutive days with the tester count held. Dropping below twelve interrupts it.
Apply. After the fourteen days you apply for production access. It is a review, not an automatic unlock, so leave buffer.

Organization accounts take a different path: they need a D-U-N-S number, which Google notes can take up to 30 days to obtain. Neither route is fast; pick based on whether you want the listing under your business name.

What resets the clock (and what does not)

The mechanics matter because guessing here costs you a fortnight.

Does not reset it: shipping new builds to the closed track. Update as often as you like — that is the point of a test.

Interrupts it: the opted-in tester count falling below twelve. Someone leaving the test, or an email address bouncing out of the tester list, is the usual cause.

Two practical implications: recruit more than twelve — aim for eighteen, because attrition is normal — and check the tester count every few days rather than discovering on day thirteen that you have been at eleven since day four.

Who your twelve should be

The instinct is to grab twelve email addresses and forget it. Do the opposite — this is the only structured testing your app will get before real customers see it.

In rough order of usefulness:

Staff. They know the catalog and will notice wrong prices.
Your most loyal customers. Ten people who buy from you monthly will find real problems, and they will feel included. Ask directly: “we’re building an app, would you test it for two weeks?”
Suppliers, wholesale contacts, your accountant. People with a relationship to the business who will not ghost you.
Family and friends, to top up the count.

Ask each of them for one specific thing rather than “let me know what you think”: have them complete a real purchase, find a product using search only, and check their order history.

Running the test without losing people

Testers drop out because they forget the app exists. Prevent that:

Tell them the length up front. “Two weeks, keep it installed, use it twice.”
Send exactly two reminders — day three and day ten. More is nagging.
Give them somewhere to report things. A WhatsApp group works better than a form, because people will type a sentence and not fill in a form.
Ship visible fixes and tell them you did. Nothing keeps a tester engaged like seeing their bug report resolved.
Thank them with something real. A discount code, early access to the next drop, their name in the release notes.

What to do with the fourteen days

Do not treat this as dead time. It is the only pre-launch QA window you will have, and there is a specific list worth working through:

Buy something on a real device with a real card. Every tester, if you can get it.
Check push notifications end to end — including order-status updates on a real order.
Test on a cheap old Android phone, not just your own. This is where layout and performance problems live.
Verify your slowest product page. The one with 40 variations and 12 images.
Confirm your store’s basics. Our WordPress plugin’s 14 store-readiness checks exist because store misconfiguration surfaces as app bugs.
Read your own store listing as a stranger would.

What to ship to Android customers meanwhile

Here is the part that makes the fourteen days bearable: you do not have to wait to have an app on Android customers’ phones.

Every StoreToNative build produces a signed APK installable from a direct link, with no Play account involved, on every plan including the trial. So during the closed-test window you can:

Put a QR code on packing slips pointing at the APK landing page.
Email your best customers a link.
Run the app-only offer to a small real audience and learn something.

There are Android security prompts a first-time sideloader has to accept, and your copy should walk them through it rather than leaving them at a scary dialog. Direct APK distribution covers exactly how that flow looks.

iOS has no equivalent for the general public — TestFlight is for testers, not customers — so the App Store path is the App Store path.

The timeline, worked backwards

If you want to be live on both stores on a specific date, work back from it:

Day −35: create the Play account and pay the $25. Enroll in the Apple Developer Program. If you want organization accounts, request D-U-N-S numbers now.
Day −28: build the app. The trial is 14 days, which is conveniently the same length as the test window.
Day −21: upload to the closed track, invite eighteen testers, confirm at least twelve opted in.
Day −7: fourteen continuous days complete. Apply for production access. Submit to Apple.
Day 0: live, with the install push ready — email, banner, QR codes.

Miss the day −35 step and everything moves, because the calendar is the constraint, not the work.

Related reading

Google’s tester and D-U-N-S requirements are documented on Google Play’s own support pages and change from time to time — check the current requirement for your account type.

Help page: Publish to Google Play, the step-by-step guide.