KADODEProduction access questions, and how to answer them honestly
Updated 2026-11-14 · Checked against Google's official help pages
The application has eight questions in three parts: three about your closed test, three about your app, and two about production readiness. Every one of them asks what actually happened during your test, so if you kept notes while testing, you can answer in your own words. Review usually takes seven days or less, but can take longer.
Where to apply
Once at least 12 testers have been opted in for the last 14 days in a row, open the Dashboard in Play Console and choose "Apply for production". You still need 12 testers opted in when you apply, so ask your testers to stay in until you hear back.
The eight questions, in Google's wording
Quoted word for word from the English help page (checked 2026-11-14). The wording inside Play Console may differ slightly.
| Part | Question | Type |
|---|---|---|
| Part 1: About your closed test | Select an option indicating how easy it was to recruit testers for your app. | Choice |
Provide details about tester engagement during your closed test, including:
| Text | |
| Summarize the feedback received from testers and describe how feedback was collected. | Text | |
| Part 2: About your app/game | Specify the target audience for your app or game. Be as specific as possible. | Text |
Describe your app or game value proposition:
| Text | |
| Select an estimated install range for your app or game during its first year. | Choice | |
| Part 3: About your production readiness | Describe any changes made to your app or game based on what you learned from your closed test. | Text |
| Describe how you determined that your app or game was ready for production. | Text |
"Review usually takes seven days or less, but can occasionally take longer."
— Play Console Help: App testing requirements for new personal developer accounts
What a good answer looks like
KADODE doesn't write answers for you, and this page has no sample answers to copy. What it can offer is a shape that fits every question.
- Use numbers and dates. Not "testers used most features" but how many testers tried which feature, and when. If you don't know a number, say so.
- Connect feedback to changes. "Feedback on day 4 said X; version 1.0.3 on day 6 changed Y." When feedback, change and release line up, your Part 1 and Part 3 answers support each other.
- Be upfront about differences from real users. If your testers were friends or fellow developers, say how they differ from your target audience and what you did about it. The engagement question explicitly asks for observed differences.
Borrowed or templated text tends not to match what happened in your own test, and mismatched answers risk being judged inadequate, which is one of the reasons developers have reported seeing in rejection notices.
What to record during the test
| Question | Keep a record of |
|---|---|
| Ease of recruiting | Who you asked, how many opted in, and where they came from |
| Engagement | The features you asked testers to try, who tried what, and which features went unused (and your guess why) |
| Feedback | Each piece of feedback with its date and channel (Play Store private feedback, email, chat) |
| Audience and value | Which testers resembled your intended users, and how they reacted |
| Changes | Each version released during the test, its date, and what it fixed |
| Readiness | Known issues left in the final build, and how you checked for crashes and other defects |
If you used a test exchange or paid testers
Say so. The first question asks how easy recruiting was, and the engagement question asks how tester behavior differed from real users. Hiding how you recruited makes those answers harder to keep consistent with your feedback summary. Explaining where testers came from, how they differ from your audience, and what you did to make up for it answers the questions as asked.
Related guides
Sources
- Play Console Help: App testing requirements for new personal developer accounts (checked 2026-11-14)