If your personal Google Play developer account was created after 13 November 2023, your launch date isn't set by the day your build is ready. It's set by Google's testing rule: a closed test with at least 12 testers opted in for 14 days in a row, then a production access review, then the review of your production release. You can't skip any of it, and Google sets most of the pace.
So if you've already told people a date (a Product Hunt launch, a newsletter, a talk, an investor), work backwards from it. This is the timeline I'd use. I run a closed testing service, so there's a disclosure at the end. Each wait below comes either from Google's help pages or from closed tests we've run, and I say which.
The timeline, backwards from launch day
| Days before launch | What happens | Where the gap before it comes from |
|---|---|---|
| 35 | Build testable, app setup done, first closed release sent for review | Google opens closed testing only after app setup |
| 31 | Release published, opt-in link live, testers start joining | My allowance for the first review, plus the several hours Google says the link can take |
| 28 | 12th tester opted in, the 14 days start | Our median: 63.6 hours to the 12th confirmed install |
| 14 | Apply for production access | Google: 12 testers, each opted in for the preceding 14 days |
| 7 | Access approved, production release sent for review | Google: access review usually takes seven days or less |
| 0 | The app goes live | Google: some accounts get reviews of up to seven days |
Five weeks, and that's the version where nothing goes wrong. Some notes on the rows.
The first closed release has to clear review and show as Published before the opt-in link appears. Google's publishing page says some accounts get more thorough reviews, up to seven days or longer in exceptional cases. I've allowed four days. Google doesn't say which accounts get the longer review, so if you can spare it, give this step a week. Before any of this, a new personal account also needs device verification with a physical Android phone and the Play Console app. Google says it takes under a minute, but you can't do it from a laptop.
The 63.6 hours comes from 112 closed tests we ran up to 1 October 2026. That's the median. One test in ten took 12 days or more (public numbers).
Production access isn't the same as being live. Once Google approves it, the Production page unlocks and your release goes through review like any other. If you want it to go live at a set hour, look at managed publishing: Google says that once a change is approved, you control exactly when it's published.
What delays the clock
The 14 days count per tester, and they only help you once 12 people are in. Here's what pushes the 12th person back.
Slow hand-offs. With an email list, each tester's Gmail has to go on your testers list before they can join. In 85 closed tests on our platform in August and September, the ones that reached 12 installs within three days had the developer adding each Gmail in a median of 3.7 hours. The ones that took more than a week: 24.7 hours. Check the list twice a day, or put a Google Group on the track so testers can join on their own.
Testers who leave. Google's FAQ says testers who opt out before 14 days don't count, and someone who opts out and back in needs 14 consecutive days again. A replacement who joins on day 10 moves your application date by about ten days. Recruit 15 or 16, not 12.
Setup mistakes that stop installs:
- Sharing the store link instead of the opt-in link from the closed track.
- A release that isn't Published yet. Google shows no opt-in link before that.
- A paid app. Google says closed testers have to buy it.
- Country limits. Google says changes to countries apply across all tracks.
- Testers on your internal track. Google says they aren't eligible for closed testing, even when they're on the closed list.
A counter that started too early. If you pay for testers, ask when their day count starts. In public reviews of closed testing services I read in October, some developers found the service had counted from its first tester rather than the twelfth. For Google, only days with 12 opted in move you forward.
What to do on each day of the 14
Day 0, when the 12th tester is in: send everyone one short message. Tell them they have to stay opted in for 14 days (Google asks you to tell them this), what to do first, and where to send feedback. That's close to Google's own advice, which asks for clear instructions, testers trying as many features as they can, and one obvious place to report things.
Days 1 to 6: a small task every two or three days, the things a real user does in their first week. Keep a log of who did what and what broke. A spreadsheet is enough.
Day 7: ask each tester for a short written note. Pick one thing they reported, fix it, and push the build to the closed track. Updates don't reset anyone's days; Google's guidance is to keep updating the app in closed testing before you release.
Days 8 to 12: a second task, ideally one that touches the fix. Count your opted-in testers. If you're about to fall under 12, recruit now. A new tester needs 14 days of their own, and it's better to find out on day 9 than on day 14.
Day 13: draft the production form outside Play Console. It has three parts: your closed test (recruiting, engagement, feedback), your app (audience, value, expected installs), and your production readiness (what you changed, how you decided it was ready). Google warns that answers are lost if you leave the page without clicking Next. I covered each question earlier in this series.
Day 14: apply while your testers are still opted in. Google checks for at least 12 when you apply. Don't wind the test down afterwards: if Google asks for more testing, testers who stayed opted in keep counting.
Review week: get the store listing, screenshots and production release ready, so they go in the day access comes through.
Buffer for a refusal and a second round
Google says you may need to keep running the closed test, for one of two reasons: fewer than 12 opted-in testers, or not enough tester engagement. The refusal email asks you to keep testing "for an additional 14 days with real testers" before you apply again.
In calendar terms, the review week is already gone when the email arrives. A second round that actually fixes engagement (new tasks, a check-in, a shipped fix) takes about two weeks; this is the plan I'd follow. Then another review of up to a week. That's three weeks. If you also lost testers and fell below 12, add the time to recruit and a fresh 14 days for the new people.
So you have two honest options:
- Start five weeks out and accept that a refusal moves your launch by about three weeks.
- Start eight weeks out. If the first application goes through, you get three spare weeks for the store listing and whatever else you're launching.
What I'd actually do: don't announce a public date until production access is approved. Announce a month. Once the Production page unlocks, the release review is the only wait left, and a date about ten days out is realistic.
Disclosure
The service I run is TestFi, one way to get the testers. A closed test is $39.99 for 16 testers, or $49.99 for 20. We guarantee that 12 are still on your test on day 14, and if fewer are, we run the closed test again at no cost, once. If Google refuses production access and its email names tester engagement, forward it within 7 days after the end date on your campaign page; if fewer than 12 testers' day 7 and day 14 notes show real use of your app, we run it again at no cost, once. That's one free re-run per closed test at most, and it's a re-run, never money back. A re-run is another 14 days, so it doesn't replace the buffer above. Details are on the closed test page.
If your date is already fixed and you're inside five weeks, put it in the comments and I'll tell you what I'd cut.
Top comments (0)