0 Get started
The roster, the invitations, and the fourteen-day clock — for the closed test Google Play makes every new personal developer account run before it will grant production access.
@pithy-sh/testers
pithy add testersGoogle Play makes every new personal developer account run a closed test — twelve testers, opted in for fourteen continuous days — before it will grant production access. Lose one on day nine and the clock effectively restarts.
There is no screen anywhere that tells you where you stand. That is the entire problem, and this is the screen.
What it sits on
The roster, the invitations and the fourteen-day window, tracked per tester rather than as a single start date.
The honest bit
Play does not publish the exact rule it applies, so the date this gives you is derived from observed behavior and stated as an estimate rather than a promise. An estimate you can see beats a rule you cannot.
If you build it yourself
The requirement is simple to state and genuinely hard to track.
The clock is per person and continuous. One opt-out on day nine effectively restarts it, and nothing tells you.
Play does not expose who is currently opted in, so it has to be tracked and reconciled.
Twelve people who are doing you a favor, chased without being annoying.
When you can actually apply — derived from observed behavior, and honest about being an estimate.
Knowing immediately, rather than on the day you tried to submit.
pithy add testersComposes with
In the dashboard
Who is opted in, for how long, and the projected date you can apply.
The dashboard is the admin interface for your own application: whatever this capability writes, your team can look up, check and act on from a browser. Reading is free, forever, with no time limit. Connect the project when you deploy.
Everything else
Each one composes the same way. Nothing you skip costs you anything.
One command installs the package, wires its bindings into every environment your project declares, and runs its migrations.