Question 1

Does this rule even apply to my account?

Accepted Answer

It applies if you publish under a personal developer account registered after 13 November 2023. Accounts registered as an organisation are exempt, as are personal accounts older than that date. One thing developers routinely get wrong: clearing the requirement once does not clear it forever. It is assessed per app, so the second app you ship runs its own fourteen days.

Question 2

Google asks for 12. Why do you put 16 or 26 on the track?

Accepted Answer

Because twelve is a floor you have to stay above for a fortnight, not a target you hit once. Run at exactly twelve and a single person changing phones on day nine drops you under the line, with no time left to recover. The extra testers are not an upsell - they are the reason the fourteen days finish rather than restart.

Question 3

What counts as a tester, as far as Google is concerned?

Accepted Answer

Someone who opened your opt-in link and joined the test. An email address sitting on your tester list counts for nothing until that person accepts, and Play Console will happily show you a list of twelve while your opted-in total reads three. That gap is the single most common reason a self-run test quietly fails to qualify.

Question 4

What actually breaks the fourteen-day streak?

Accepted Answer

Your opted-in count falling below twelve at any point, or the closed track itself going away - unpublished, paused, or the release rolled back. Those are the failure modes worth guarding. Adding testers mid-window is harmless, and so is a tester who installs but has a quiet day.

Question 5

Can I keep shipping builds while the test runs?

Accepted Answer

Yes, and you should if you have fixes worth shipping. Uploading a new release to the same closed track does not restart the counter. What does hurt you is halting the track or removing the release while testers are mid-window, so push updates rather than pulling the rug.

Question 6

Who is on the other end, installing my app?

Accepted Answer

Paid testers we work with directly, on the Android phone they carry every day, signed in to the Google account they have had for years. No emulators, no freshly minted accounts, no device farm handing out the same hardware fingerprint to two hundred unrelated apps. That last one is what gets developer accounts flagged, and it is the whole reason this is worth paying for.

Question 7

Could paying for testers put my developer account at risk?

Accepted Answer

Not in itself. The policy sets out how many testers you need and for how long; it does not require that they be your friends. What draws enforcement is fabricated participation - bulk-created accounts and simulated sessions - because that is trivially detectable and is what the cheap end of this market is quietly selling. Ask any provider how their testers are sourced, and treat a vague answer as the answer.

Question 8

My app needs a login, an invite code or a paid plan. Can it still be tested?

Accepted Answer

Yes, but tell us at submission. Hand us test credentials, a demo code, or a build flag that unlocks the paid tier, and testers can reach the parts of the app that matter. Without that they stall on your sign-in screen, which produces fourteen days of activity that proves very little and feedback worth even less.

Question 9

What do testers see of my app, and can they talk about it?

Accepted Answer

They see the build you put on the closed track, and nothing else - no source, no console access, no analytics. Everyone testing through us is under a confidentiality agreement covering unreleased builds, so your app is not being posted about while it is still unannounced. If you need something firmer than that for a client project, ask us before you buy.

Question 10

Where are your testers based, and does it change anything?

Accepted Answer

Across Europe, South and South-East Asia, and the Americas. For the requirement itself it makes no difference - Google counts testers, not passports, and your store availability is a separate setting entirely. It does matter for the quality of the feedback, so if your app is regional or single-language, say so and we will weight the roster your way.

Question 11

Realistically, how much of my time does this take?

Accepted Answer

About five minutes at the start and none afterwards. You add our Google Group to the track, paste the opt-in link into your dashboard, and stop thinking about it. There is no daily check-in, nothing to approve, no reminder emails to send. Watch the count climb if you like it, or close the tab and come back on day fourteen.

Question 12

Day 15 arrives. What am I actually filling in?

Accepted Answer

Play Console unlocks a questionnaire of roughly ten questions about how you recruited testers, what you learned, and what changed as a result. It is read, not merely collected, and thin answers are the second most common reason applications come back. We hand you draft answers written from your test - real dates, real numbers, real feedback - for you to edit into your own voice.

Question 13

I was already turned down once. Does that count against me?

Accepted Answer

No - a previous refusal does not blacklist the app or the account, and roughly a third of the apps that come to us have been through it. What we do differently is read the refusal first. Re-running the identical test with a fresh set of testers tends to produce the identical result, so we would rather find out whether the problem was the test or the answers before you pay for another fortnight.

Question 14

If Google says no again, what happens in practice?

Accepted Answer

Email us the refusal, and we refund the full amount to the original card - no form to fill in, no requirement that you argue your case. The condition is simply that the test ran its course: fourteen consecutive days, tester count held above the line. If you would rather run it again than take the money back, we will do that instead.

Question 15

How does payment work if I have several apps to ship?

Accepted Answer

It is one-time per app - no subscription, nothing to cancel. Cards go through Stripe, with local methods including UPI where they are supported, and we never see the card details. If you are shipping several a quarter, buy credits in a pack: they cost less per app, they never expire, and each app draws one down when you submit it.

The questions developers actually send us

Stop chasing twelve people