My app was finished. I thought I could put it on the store.
I couldn’t.
New personal developer accounts have a requirement you have to meet before you can publish to production:
12 testers must have been opted in to your closed test continuously for 14 days
I thought, “So I just wait 14 days.” Nope. When I worked backward, it turned out that going from the start of testing to public release takes at least 29 days.
The actual backward calculation
Here’s the schedule I actually built. I’ll call the test start date D0.
| Step | Duration | Cumulative |
|---|---|---|
| Closed testing (12 testers × 14 days) | 14 days | D0+14 |
| Let it sit after the test ends | 3 days | D0+17 |
| Apply for production access through approval | 7 days | D0+24 |
| Store publishing review | 3–5 days | D0+27–29 |
In other words, from the day you’ve finished gathering testers and started the clock, it’s just under a month until public release.
The easy-to-miss part: the “+3 days”
The first backward calculation I built was wrong.
I figured, “Once the 14 days are over, I’ll apply for production access right away,” and calculated it as D0+24–26 days. That underestimates the real timeline by 3 days.
What I’d left out was the practice of not applying right after the 14-day test period ends. You let it sit for about 3 days, then apply.
The reason is that there’s a lag before Google tallies the “14 days of continuous participation.” If you apply right after the test ends, you risk being sent back as not meeting the requirement. I had included this waiting period for another app I released earlier, but it slipped out of the plan for the next one.
A 3-day gap is fatal when you have a deadline. In my case, this correction pulled a plan whose “safe final cutoff” was supposed to be September 2 forward to a practical limit of August 27.
The most dangerous trap: internal testing doesn’t count
This was the biggest pitfall.
Google Play has several testing tracks:
- Internal testing
- Closed testing
- Open testing
I’d been doing my functional testing on internal testing. I had testers in it, too. I thought things were going smoothly.
Internal testing does not count toward the 12 testers × 14 days requirement.
Only the closed testing track can satisfy it. No matter how long you run internal testing, not a single day accumulates.
When I realized this, one of my apps didn’t even have a closed testing track created yet. In other words, D0 hadn’t even started. I’d been thinking “I’ve been testing for 2 weeks already, so I can launch soon,” when in reality I was at day zero.
Using internal testing for functional checks is the right call, but it’s a completely separate thing from meeting the requirement. Mix the two up and you lose 2 whole weeks.
And the really hard part: finding 12 people
I’ve mostly talked about days, but in practice this is the heaviest part.
As an indie developer, finding 12 people who have Android, will give you their Google account, and will go through the opt-in steps is far harder than you’d imagine.
Breaking down the conditions:
- They own an Android device (iPhone users don’t qualify)
- They trust you enough to give you their Gmail address
- They’ll open the URL you send and complete the opt-in
- They won’t drop out as testers for 14 days
iPhone has a high share of the smartphone market in Japan, so the pool of candidates shrinks a lot the moment you try “ask my friends.” At first I had only 2 confirmed. I started out 10 people short.
On top of that, testers aren’t “add them and you’re done.” If someone opts out or cleans up their accounts partway through the 14 days, the count breaks. So the realistic move was to aim for about 15, not exactly 12.
What worked: asking testers from an app I’d already released
In my case, this was the decisive move.
From your 2nd app onward, you have people who were testers for your previous app. They already meet 3 of the conditions:
- They definitely own an Android device
- You already know their Gmail address
- They’ve been through the opt-in steps once before
The 3rd one is especially big. The cost of explaining the steps to a first-timer drops to zero. And since it’s a different app, there’s no restriction on joining multiple tests at the same time.
You can also create good timing. If you reach out around when the previous app’s 14 days are up, it becomes a natural “That one’s done, could you help with the next one too?”
The 1st app is the most painful, and it gets easier from the 2nd one on. That’s how it’s structured. If you’re just starting out, I think you should set aside the most time for recruiting testers for your 1st app.
A caution when asking people to test
There’s just 1 spot where getting the order wrong can do real harm to the other person.
Finish registering them for license testing before you send the opt-in URL.
If you skip this registration, a tester who goes through a purchase in the app may actually get charged. Asking someone to test your app and then leaving them to pay real money is out of the question, so always stick to this order.
Summary
- It only counts on the closed testing track. Internal testing counts as zero days no matter how long you run it
- From the end of testing to launch takes nearly another 2 weeks. 14 days + 3 days + 7 days + 3–5 days, for a total of 27–29 days
- Finding 12 people is the real work. Recruiting is harder than waiting out the days
- It gets easier from the 2nd app. Asking the previous app’s testers is the most reliable approach
If you’re working backward from a release date, you need 12 testers lined up and a closed testing track already created at least a month before the date you want to launch. If you’re targeting a contest or campaign with a deadline, leave even more buffer.
I got this calculation wrong once and lost 3 days of buffer. Doing the same math up front would have prevented it.
On the store side, I’ve also written about getting rejected over the screenshot resolution requirements and 3 crashes that only happen in release builds.