If your personal Play Console account was created after November 13, 2023, you need at least 12 testers opted in to a closed test for 14 days in a row before you can apply for production access. Plenty of offers now promise to cover that for a few dollars. Some are fine. Some leave you with a count that never reaches 12, or ask for things you should never hand over.

So here are the questions I'd ask any $8 tester offer before paying. Disclosure: I run 12testers, which is one of those $8 offers, so under each question I've put what our live pricing, how-it-works and FAQ pages say. Hold us to the same list.

Get 12 testers for $8 if you've already done your homework. One plan, $8 one-time per app, no subscription.

The seven questions I'd want answered in writing before paying anyone for testers.

1. Are these real phones with real Google accounts?

This is the first thing I check, because the testers have to be people (or devices) that can actually opt in to your closed track and install from Google Play. Ask what kind of hardware is behind the offer and whether each tester is a separate Google account.

What 12testers says: "14 Real Physical Android Devices & Google Accounts." The FAQ adds that the pool uses physical Android phones across multiple manufacturers and Android versions, and that no Google endorsement or hardware certification is claimed.

2. Do they need my password or Play Console access?

They shouldn't. A closed test only needs testers to be on your track and to accept the invite. If an offer asks for your Google password, your Play Console login, an API key or to be added as a user on your developer account, walk away. That's your whole account on the line for a few dollars.

What 12testers says: "No Play Console Password or Credentials Required." You either add the Google Group or share your web opt-in link. The FAQ says it plainly: never send a password, API keys or private Play Console credentials.

3. How exactly do testers opt in?

Vague answers here usually mean trouble later. There are really only two clean routes in Play Console: add testers on the closed track's Testers tab (an email list or a Google Group), or share the web opt-in link. Ask which one the offer uses and what you have to do on your side.

What 12testers says: open Closed testing, go to the Testers tab, and add the Google Group testers@12testers.pro, or share your opt-in link. Per the FAQ, the devices usually join within 12 to 24 hours, and the testing window starts once the release and opt-in route are verified as accessible. Step 2 on the how-it-works page also says you can confirm the opted-in count in your own Play Console, which is what I'd want anyway.

One thing on your side: the release on the closed track has to be rolled out and available before anyone can join. No offer can fix a draft release.

4. How many testers, and how long is the window compared to 14 days?

Exactly 12 testers for exactly 14 days leaves zero margin. Google's rule is about testers opted in continuously. If someone opts out and back in, their 14 days have to start again. So I ask two things: how many testers start, and how long they stay.

What 12testers says: 14 devices for 16 continuous days. That's two testers of capacity above 12 and a "Two-Day Operational Buffer Beyond the 14-Day Minimum," with opt-in and tester continuity monitoring across the window. The FAQ is careful to say your own Play Console remains the authority on the count.

5. What do I get at the end?

When the window closes, you're going to fill in the production access questions yourself. It helps to have a record of what happened during the test. Ask whether the offer gives you anything at all, or just disappears after day 14.

What 12testers says: a "Closeout Summary for Your Production-Access Preparation." The how-it-works page says to use that run record together with your own tester feedback when you apply. Testers' feedback lands in your Play Console, so it's worth reading it before you answer the form, and the answers about your app have to come from you.

Same price range, very different risk. The difference is what's written down before you pay.

6. What happens if the testers don't stay?

This is the question most cheap offers skip. Ask what happens if the count drops below 12 because of their side, and how you'd prove it.

What 12testers says: the pricing card states, "If fewer than 12 testers stay opted in for 14 days, we re-run your test free or refund your $8." The refund policy spells out what's eligible: the run wasn't provided, a confirmed service-side continuity failure, or a duplicate charge. To ask for a review you email support@12testers.pro with your order reference, package name and a Play Console screenshot.

What it doesn't cover is just as important. Google's decision on production access, review timing, policy compliance and app quality sit outside the warranty. A denial from Google doesn't by itself mean the test failed.

7. Is $8 the whole price?

Cheap offers sometimes turn into a subscription or a list of add-ons at checkout. Ask whether it's one payment, per app, and what you'd be charged later.

What 12testers says: one plan, $8.00 per app, one-time, "Single Price · Zero Add-Ons," no subscription. Checkout runs through Dodo Payments, and the FAQ says any optional or changed scope must be shown before checkout.

The red flag that ends the conversation

Anyone who promises your app will be approved. Nobody outside Google can promise that. Google reviews your app, your account, your policy declarations and the testing evidence, and review usually takes 7 days or less after you apply. A tester service can help you meet the 12-testers-for-14-days part. That's it.

12testers says this on every page: completing a test does not guarantee production access, and Google makes the final decision. If an offer says otherwise, I'd trust the rest of its page less too.

What I do before I pay anyone

1. Roll out the release on the closed track and select countries, so the opt-in link actually works.
2. Open the opt-in link once from a second Google account to make sure it isn't a dead end.
3. Run through the seven questions above and save the answers (a screenshot of the pricing page is enough).
4. Pay, add the group or share the link, and watch the opted-in count in Play Console for the first couple of days.

The live 12testers pricing card, captured on October 29, 2026.

If our answers hold up against your list, the plan is here:

Get 12 testers for $8

Get 12 testers for $8

Why you're here in the first place

If your Google Play developer account is a personal account created after November 13, 2023, Google wants at least 12 testers opted in to a closed test for 14 days in a row before you can apply for production access. Finding 12 people who will install your app and stay opted in for two weeks is the hard part. Friends forget, opt out, or join with the wrong Google account, and the count drops below 12 on day 9.

That's the gap the $8 plan is for.

What the $8 covers

From the pricing page, one managed closed test is a one-time $8.00 per app, paid through Dodo Payments checkout. No subscription. It includes:

• 14 real physical Android devices with their own Google accounts
• a 16-day testing window, which leaves a two-day buffer past Google's 14 days
• opt-in and tester continuity monitoring during the run
• a closeout summary you can use while preparing your production access application
• no Play Console password or credentials needed

If fewer than 12 testers stay opted in for the 14 days, the run is re-done free or the $8 is refunded. Google's production access decision is still Google's. Nobody can sell you approval, and anyone who promises it is guessing.

Step 1: Add the tester group to your closed track

After you pay, you either share your closed track's web opt-in link or add the Google Group testers@12testers.pro in Play Console:

1. Open Test and release > Testing > Closed testing and pick your track.
2. Go to the Testers tab.
3. Add testers@12testers.pro as a Google Group, save, and make sure your release is rolled out to that track.

Don't send a Play Console password, API key or anything private. It isn't needed and you shouldn't share it with anyone.

Step 2: The devices join

The FAQ says the devices usually join within 12 to 24 hours after the group is added or the opt-in link works. The testing window starts once the release and access route are verified. You can watch the opted-in count go up in your own Play Console, which is the number that matters.

A tip from my own launches: check that the closed track has the right countries selected and that the release isn't still sitting in review. If the opt-in link says the app isn't available, testers can't join no matter who they are.

Step 3: Sixteen days of active testing

During the 16 days the tester continuity is monitored, so an opt-out gets noticed early instead of on day 14. Google counts 14 consecutive days, so the extra two days are breathing room, not a requirement.

Use that time well. Ship a bug fix or two to the same track, read Android vitals, and write down what you changed. Google's production access form asks about your testing, and "I fixed X after testers hit it" is a much better answer than "nothing happened."

Step 4: Closeout and applying

At the end you get the closeout summary. Combine it with your own notes and apply for production access from the Play Console Dashboard. Then Google reviews the app, the account, policy compliance and the testing evidence.

Is $8 worth it for you?

If you already have 12 reliable people who will stay opted in for 14 days, you don't need to pay anyone. If you've tried that and the count keeps slipping, $8 is less than most people spend on coffee during the two weeks they'd otherwise spend chasing testers.

Get 12 testers for $8

Compatibility on Google Play comes from your app bundle and your Play Console settings, not from the tester. So the fix is almost always on the developer side. Here's the order I go through it.

The usual suspects, in the order I check them. Example states only.

1. minSdk is higher than the tester's Android version

This is the most common one. If your minSdk in build.gradle is, say, 28 and the tester's phone runs an older Android version, Play hides the install button and shows the compatibility message. Ask the tester for their Android version (Settings, About phone) and compare. If you don't need a newer API, lowering minSdk and uploading a new version code is the fix.

2. A required hardware feature in the manifest

Every <uses-feature> in your merged manifest is treated as required unless it says android:required="false". A camera, NFC or a specific sensor you only use on one screen can lock out phones that don't have it. Libraries can add these too, so check the merged manifest in Android Studio, not just your own file. Permissions can also imply features, for example camera permission implies a camera.

3. Native libraries for only some CPU types

If your app ships native code (a game engine, an SDK with .so files) and you only built for arm64-v8a, phones that need another ABI won't be offered the app. Look inside your bundle with App Bundle Explorer in Play Console to see which ABIs are actually included.

4. A device exclusion rule you forgot about

Play Console has a device catalog where you can exclude specific devices or whole groups, for example by RAM or Android version. I once excluded low-memory phones for an earlier app and copied the setup without thinking. Open the device catalog, search the tester's phone model, and see whether it's marked as supported or excluded and why. Google notes that changes to device exclusion rules aren't held back by managed publishing, so a fix there doesn't wait for "Publish changes".

Where each check lives in Android Studio and Play Console.

5. It's not compatibility at all

Sometimes the tester reads "not available" and reports it as "not compatible". These are different. "Not available" usually means the account isn't on the tester list, they opted in with another Google account, or the release isn't published to the closed track yet. Ask for a screenshot of the exact message before changing your build.

What this does to the 14 days

Google's rule for personal developer accounts created after November 13, 2023 asks for at least 12 testers opted in continuously for at least 14 days before you apply for production. A tester who can't install still sits on your list, but if they give up and opt out, they stop counting, and if they opt out and back in the 14 days have to be consecutive. So I fix compatibility in the first day or two, not on day ten.

My rule now: before I share the opt-in link, I look up two or three real tester phones in the device catalog. It takes five minutes and saves a restart.

When you just need enough testers who can install

If your own circle is mostly the same few phones, or you can't reach 12 people at all, 12testers runs budget Google Play closed testing for $8 per app: 14 physical Android devices across multiple manufacturers and Android versions join through a Google Group on your Testers tab, monitored over a 16-day window. You don't share your Play Console password. Google still decides on production access, and your app still has to install on those phones, so the checks above come first.

12testers.pro, the $8 closed test option. Screenshot taken October 2026.

These days I treat the production access application as a short report on my closed test. Here's how I fill it in, section by section, and what I prepare before I even open it.

First, check you're actually eligible

For personal developer accounts created after November 13, 2023, Google asks for a closed test with at least 12 testers opted in continuously for at least 14 days. Before applying I open Test and release > Testing > Closed testing and confirm two things: the opted-in count is 12 or more, and nobody dropped out and rejoined late in the window. If a tester opts out and back in, their 14 days have to be consecutive again.

If either one is shaky, I wait a couple of days. Applying early only sends you back to testing.

Gather three things before you open the form

I keep a plain text file per app with:

1. The test window. Start date, end date and the opted-in count on the last day. A screenshot of the Testers tab helps me stay honest about numbers.
2. A feedback log. Every useful comment, where it came from (Google Play private feedback, email, a chat), the date, and what I did about it. Play Console keeps the private feedback under Monitor and improve > Ratings and reviews > Testing feedback.
3. A change list. Version codes I shipped during the test and one line on what each fixed.

With those three in hand, the form takes twenty minutes instead of an evening of guessing.

Section 1: About your closed test

This part asks how you recruited testers, how easy it was to get them, and how engaged they were. I answer it like I'd explain it to another developer:

• Who the testers were. Friends, a dev community, a tester group, a managed service. Say it plainly.
• What I asked them to do. I list the actual tasks: sign up, finish the main flow, try the new screen, report anything that felt broken.
• What came back. A few real examples from the feedback log, written in my own words. Not "testers loved it". Something like "two testers said the onboarding skipped the permission screen on Android 14, fixed in version 7".

If engagement was low, I say so and say what I'd do differently. Vague answers are what make this section weak.

Section 2: About your app

Here I describe who the app is for and what it does in normal words. One short paragraph on the audience, one on the main features, and a note on anything that needs a login. If the app needs an account, I make sure the test credentials in App content still work, because a reviewer who can't log in can't review anything.

Section 3: Production readiness

This asks what you changed based on the test and how you decided the app is ready. My change list answers the first half directly. For the second half I mention the checks I ran: no crashes on the devices testers used, store listing and content rating filled in, data safety form updated after any new SDK.

Google reviews the application, and the help page says it usually takes 7 days or less. The decision is theirs. All the form can do is show them a real test happened and you acted on it.

A short template I reuse

Testers: [who] recruited via [how]. [N] opted in on the closed track from [date] to [date].
Tasks given: [task 1], [task 2], [task 3].
Feedback: [example 1 + fix + version], [example 2 + fix + version].
Changes: version [x] fixed [y]; version [z] improved [w].
Ready because: [checks you ran].

I fill in the brackets from my notes and then rewrite each line so it reads like me, not a template.

If you don't have enough testers yet

Getting 12 people to stay opted in for 14 straight days is the hard part for a solo developer. I wrote up honest ways to frame these answers, with frameworks for each question, over on 12testers: Google Play production access questions: honest answer frameworks. 12testers also runs a managed closed test for $8 per app if you'd rather not chase testers yourself, though the feedback and the answers still have to come from you.

This is the reapply checklist I use now. It's split into what Google says matters and the habits I follow on my own tests.

What Google says can send you back to testing

Google's Play Console Help names two reasons an app may need to keep running its closed test: fewer than 12 opted-in testers, or not enough tester engagement during the test. On top of that, the help page lists the policy areas to double-check before applying: app content and features, target audience and content rating, functional reliability (no crashes, broken functionality or missing screens), and working test credentials if your app needs a login.

That gives you a clear list to work against instead of guessing.

Step 1: Don't stop the closed test

The instinct is to pause everything and rethink. That's the wrong move. Your testers need to stay opted in continuously, and if they leave and rejoin, their 14 days have to be consecutive again. Keep the closed track live and tell your testers you're still testing.

Step 2: Recount testers on the closed track

Go to Test and release > Testing > Closed testing and open the Testers tab. Compare it with who actually accepted the invite. People on Internal testing don't count, and people who opted in with a different Google account than the one you added don't count either. I aim for a few more than 12 so one dropout doesn't undo the window.

Step 3: Give testers something specific to do

"Please test my app" rarely gets much back. What works better is a short message with two or three concrete tasks: create an account, finish the main flow, try the feature you just changed, and tell me what felt confusing. Then ask them to send feedback through Google Play's private feedback or my own feedback email.

Step 4: Read and log the feedback

Testing feedback lives under Monitor and improve > Ratings and reviews > Testing feedback. I copy each useful comment into a simple log with the date, the device or Android version if they mentioned it, and what I did about it. When you apply, you have to summarise the feedback and how you collected it, so this log turns into your answer.

Step 5: Ship at least one update on the closed track

The application asks what you changed based on the closed test. "Nothing" is a weak answer. Fix the crash a tester hit, reword the confusing screen, and publish the new build to the closed track first. Then you can describe a real change, with a real reason, in your own words.

Step 6: Clean up App content before you reapply

• Check target audience and content rating against what the app really does.

• If the app has a login, add working test credentials and short instructions in the app access section, so the reviewer can get past your sign-in screen.

• Open the app on a fresh install and make sure every screen loads. A reviewer who hits a blank screen sees broken functionality.

Step 7: Rewrite the three answer sections honestly

The form has three parts: about your closed test, about your app, and about your production readiness. I write each answer from my log: how I recruited testers, what they used, what they reported, what I changed and why I believe the app is ready. Specific and true beats polished and vague every time. Review usually takes seven days or less, and the result goes to the account owner's email.

If tester numbers were the problem

When the honest recount shows you simply didn't have 12 people opted in for 14 days, fix that first. Friends, classmates and small communities around your app's topic are the usual route. Another budget option is 12testers.pro, which runs one managed closed test for $8 per app with 14 physical Android devices and opt-in monitoring over 16 days. It still doesn't guarantee approval; Google reviews the app, the account and the testing evidence. Their write-up on why Google Play production access gets denied and what to fix goes deeper into the common causes.

A rejection here isn't a ban. It's Google telling you the test or the app isn't there yet. Keep the testers in, make one honest round of improvements, and apply again with answers you can back up.