🚀 Tips for the production access application

Personal developer accounts must submit the **Apply for production access** form in Play Console after the closed test. A rejection means running the 14-day test again, so preparing properly the first time is far cheaper. This guide is based on Google's official documentation and real rejection and approval cases.

## Get the requirements right - **12 or more testers** must stay opted in for **14 consecutive days**. (The old threshold was 20; it is now 12. Older posts still say 20.) - A tester who **opts out before day 14 does not count.** With exactly 12, one dropout breaks the requirement. Recruit 14 to 16. - **The internal testing track does not count.** It must be the closed testing track. - Someone who only taps "Become a tester" on the web and **never installs does not help.** Share the opt-in link together with install instructions. - Review usually takes seven days or less. Fast decisions arrive in about two days.

## A real case: rejected in 5 hours, approved in 2–3 days A developer shared this experience publicly. - **First attempt**: 12 testers, 14 days, then applied → **rejected in under 5 hours**. Reason: "testing was insufficient". Looking back, two things were missing. The Play Console **private feedback channel was never used**, and **no app update was published** during the two weeks. - **Second attempt**: asked every tester to leave private feedback through the Play Store, and shipped **4 consecutive updates** acting on it (feature additions, a same-day patch, bug fixes), each checked by several testers → **approved after 2–3 days**. - Their conclusion: "If you don't want to waste two more weeks, have testers write store feedback and publish at least 2 app bundle updates." The point is **the traces left during the test, more than the form.** Google looks at whether testing really happened, not at the install count.

## Why applications get rejected Google's rejection email says little more than "your app requires more testing". The causes below are the ones developer communities and testing services keep reporting. (Not an official Google statement.) 1. **Testers install but never open the app**: 12 people join on day one and nobody returns, which looks like a box-ticking swap 2. **Zero updates during the test**: no evidence that feedback led to fixes 3. **One-line form answers**: using 30 characters of a 300-character field is the most common mistake 4. **Unresolved crashes or ANRs** in the pre-launch report 5. **Applying at exactly day 14**: compliant but empty-looking. Run a day or two longer 6. **Incomplete store listing, Data safety section, or privacy policy** 7. **Country restrictions on the testing track**: testers in excluded countries cannot install 8. **Overwriting the tester email list**: uploading a new CSV replaces the previous one. A Google Group avoids this 9. **Login-gated app with no test credentials provided**

## What to do during the 14 days - **Ship 2 to 3 updates.** Fix what testers reported, bump the version, and say what changed in the release notes. - **Pick a feedback channel** and tell testers: Play Store private feedback, email, or chat. The communication tab of your SmallDev request also leaves a record. - **Get specific feedback.** "Settings reset when I go back" proves a real person tested; "looks good" does not. - **Ask testers to reopen the app every few days.** The SmallDev participants tab shows retained installs and launches. - **Check Android vitals and the pre-launch report** and fix crashes first.

## The form: 3 parts, 9 questions The wording shifts over time, but the content stays the same. ### Part 1. About your closed test 1. **How did you recruit testers?** State the real source. Friends, developer communities, exchange services, and paid testing providers are all accepted by Google. Do not dress it up; a mismatch with reality is the actual risk. Example: "I recruited 14 testers from an Android developer community and a tester exchange service (SmallDev); all opted in within the first two days." 2. **How easy was it to recruit testers?** (multiple choice) There is no right answer. Pick what you experienced. 3. **Describe tester engagement** (did they use all features, did usage match real users) Describe **user journeys**, not "regular use". Example: "Testers completed sign-up → goal setup → logging → statistics, on a Galaxy S23, a Pixel 7, and an A-series device. 9 of 12 reached the payment screen." 4. **Summarize the feedback and how you collected it** Collection method plus 3 to 5 concrete issues. Bugs are not a penalty; they show the test worked. ### Part 2. About your app or game 5. **Who is the intended audience?** Avoid "everyone". Narrow it to who uses it and in what situation. 6. **What value does the app provide?** Not a feature list: **problem → experience → benefit**. 7. **Expected installs in the first year** (range). Be realistic. For an indie app with no audience, the lowest range is natural. ### Part 3. About production readiness 8. **What did you change based on the closed test?** It must **pair with answer 4**. Cite version codes. Example: "Google sign-in failure reported → fixed in 1.0.2 (code 5); janky list scrolling → pagination added in 1.0.3 (code 6)." 9. **How did you decide the app is ready for production?** You do not need to claim perfection. State your criteria. Example: "Core flows run without reproducible errors on three devices, zero new crashes in the last 5 days of testing, all blocking bugs resolved."

## Writing tips - Fill the field. Around **250 to 300 characters** per answer works well - **Numbers and names**: people, dates, device models, feature names, version codes - Make answers **interlock**: 4 (feedback) ↔ 8 (changes) ↔ 9 (readiness) - **Be factual.** Answers that contradict your actual test record are the biggest risk - English is fine

## If you were rejected - The email usually says something like "your app requires more testing" - You must complete **another 14-day test** before the apply button returns - Do not repeat the same 14 days. Do the items under "What to do during the 14 days", then reapply. As in the case above, updates and feedback traces change the outcome

## If it is hard, let an LLM draft it Give ChatGPT, Claude, or Gemini the form's questions and the facts below and you get a draft in the right shape. **Fix anything that is not true** before you submit. ``` I am the developer of the Android app "<app name>" (<one-line description>). I need to answer the Google Play production access application form (3 parts, 9 questions). - Testers: <N>, recruited via <community / SmallDev exchange / friends>, from <start> to <end> - Journeys testers actually used: <sign-up → ... → ...>, devices: <models> - How feedback was collected: <Play private feedback / email / chat> - Feedback received: <1> / <2> / <3> - Changes made with version codes: <1 → how, code N> / <2 → how, code N> - Updates published during the test: <N> - Why I consider it ready: <crash-free period, verified flows> - Target users and value: <who, what problem, what benefit> Answer each question below in 250 to 300 characters, using the numbers and feature names above verbatim. Do not invent anything; use only what I gave you. <paste the form questions> ```

## Sources - Google Play Console Help — App testing requirements for new personal developer accounts - A developer's first-hand write-up (rejected in 5 hours, approved after 4 updates) - Rejection causes compiled by developer communities and testing services