Google Play makes every new personal developer account run a closed test with at least 12 testers opted in for 14 continuous days before it will grant production access.
There is no screen anywhere that tells you where you stand. Lose one tester on day nine and the clock effectively starts again, and you find out by the count not moving.
@pithy-sh/testers runs that process: a cohort with a target and a window, a roster you invite by email from your own domain, a one-tap confirmation link that needs no account, and a fourteen-day clock replayed from your own event log — so a correction is a recomputation rather than an overwrite.
The clock is honest about what it is
Pithy’s count is an estimate from your own invite records.
Google’s count is authoritative, and no API exposes it — not the roster, not the number, not a tester quietly opting out. That is not a gap somebody will close; it is what the Play Developer API does and does not offer.
So every figure derived from it is named estimated, the response carries that sentence as a required field, and nothing here claims to read the console. A dashboard that showed you a number implying otherwise would be worse than no dashboard.
What Pithy can read is activity, and that is the part nobody else has
Resolve each tester to their user through auth and you learn who has actually opened the app.
A tester dark for eight days shows up on day eight, rather than on day fourteen when the count finally moves and it is too late to do anything about it.
Two blocks, and they never blend: the estimated clock carries source: "pithy_estimate" as a literal discriminator, and the activity block carries source: "observed". One is a guess about Google; the other is a fact about your own app.
One step it cannot do for you
Adding an address to Play’s own tester list. The Play Developer API has no way to do it, so you paste them into the console.
pithy testers pending prints exactly the addresses waiting for that step. Until it is done the store link answers App not available, which is why the second email waits for you rather than going out and confusing somebody.
The daily pass
A Workflow runs each morning: advance state, chase whoever needs chasing under a mandatory per-tester cooldown, and write one snapshot per cohort per day.
That snapshot is what makes the trend chartable at all. Activity cannot be reconstructed after the fact the way an event log can — how many were active last Tuesday is only answerable if something recorded it on Tuesday.
Four kinds of nudge: will you test, here is the store link, you have been quiet, the window is closing. Every one ships default copy, so this works from the CLI with no dashboard.
A management client may override the words as plain text and never as markup, because those words go out over your own DKIM signature.
The CLI is not the paid tier
Every operation the control-plane routes expose has a command in pithy testers, each non-interactive and each with --json.
The dashboard is a nicer way to look at the same rows. It is not where the capability lives.
What it deliberately does not do
It does not read the Play Console. Covered above, and it is the single most important thing to understand about this capability.
It does not submit your app, manage releases, or upload a bundle.
It does not enroll testers into Play’s list. The one manual step.
It does not handle iOS. A cohort can be marked ios, and TestFlight has no equivalent fourteen-day requirement — the machinery is here for symmetry rather than because Apple needs it.
When you would reach for it
If you have a new personal Google Play developer account and a launch date, this is between you and production. It is a narrow capability for a narrow bureaucratic requirement, and it exists because that requirement is real and undocumented in practice.
Not for beta programs generally. If you already have production access, a mailing list and TestFlight are simpler.
What it needs
It requires email — an invitation is a message, and the roster is worked by mail.
auth is optional and is what unlocks the activity half. controlplane, audit and secrets are each optional.
pithy add testers writes bindings and touches no account. The daily-pass Workflow arrives with pithy testers provision, which also needs the project’s shared email-suppression database — so pithy email provision has to have run.