Google Play Launch Checklist: From Signed Build to Production

Getting an Android app from "it runs on my phone" to "it is live on Google Play" involves more steps than most first-time publishers expect. None of them are hard, but missing one can cost days of back-and-forth with review. Here is the checklist we use, in the order the work actually happens.

Step 1: Set up the developer account early

Create the Google Play developer account well before the app is finished. Identity verification for individuals and organizations can take several days, and organization accounts need a D-U-N-S number, which can take longer to obtain if you do not already have one.

• Decide between a personal and an organization account. Organization accounts show your company name as the developer and are better for client work and teams.
• Use a shared company email address for the account, not a personal inbox that may leave with an employee.
• Add teammates with their own logins and limited permissions instead of sharing a password.

Step 2: Plan for closed testing

New personal developer accounts must run a closed test with a minimum number of testers who stay opted in for a continuous period before they can apply for production access. The exact numbers are shown in Play Console for your account, so check there rather than relying on old blog posts. In practice this means you should recruit testers early and start the closed test as soon as you have a stable build.

Treat this as a real test rather than a formality. Ask testers to use the app over several days and collect their feedback, because Google asks about your testing when you apply for production access.

Step 3: Prepare the release build

1. Build an Android App Bundle (.aab), which Google Play requires for new apps.
2. Enroll in Play App Signing and keep your upload key backed up in at least two safe places. Losing it means a key reset request, not a lost app, but it is still a delay you can avoid.
3. Make sure the app targets the API level required by Google Play's current target API policy.
4. Set versionCode and versionName deliberately. Every upload needs a higher versionCode than the last.
5. Remove debug logging, test ad unit IDs and development server URLs from the release configuration.

Ads tip: always use test ad units during development and switch to real ad unit IDs only in the release build. Clicking your own live ads can get an AdMob account restricted.

Step 4: Complete the App content section

Play Console's App content page lists every declaration your app needs. Production release is blocked until all of them are complete. Expect to fill in:

• Privacy policy URL, hosted on a public web page.
• Ads declaration: whether the app contains ads.
• App access: login credentials or instructions if parts of the app are behind a login, so reviewers can test it.
• Content rating questionnaire.
• Target audience and content, including whether the app appeals to children.
• Data safety form, covering your own data handling and every SDK you include.
• Account deletion link, if users can create accounts.
• Other declarations as relevant: government apps, financial features, health features, news, and so on.

Answer the target audience questions honestly. If your app could reasonably attract children, Families policy requirements apply, which affect which ad networks and SDKs you are allowed to use.

Step 5: Build a store listing that converts

The store listing is your app's landing page. Reviewers also check it for policy issues, so accuracy matters as much as marketing.

• App name: short and clear, without keyword stuffing, emoji or claims like "#1" or "Best".
• Short description: one sentence explaining the main benefit.
• Full description: what the app does, key features and who it is for. Write for people, not search algorithms.
• Graphics: a 512×512 icon, a 1024×500 feature graphic and real screenshots from the app. Screenshots that show features the app does not have are a policy violation.
• Developer contact: a monitored email address and your website. The website is also where AdMob looks for app-ads.txt.

Step 6: Roll out carefully

Once you have production access, you do not have to release to everyone at once. A staged rollout lets you start with a small percentage of users and increase it as crash and ANR rates stay healthy. If something goes wrong you can halt the rollout while you fix it.

Review times vary. First submissions and apps with sensitive permissions usually take longer, so do not schedule a launch announcement for the same day you submit.

Step 7: The first week after launch

1. Watch Android vitals in Play Console for crash rate and ANR rate. Bad vitals reduce your visibility in the store.
2. Read and reply to reviews. Early reviewers often point at real bugs, and replies show future users the app is maintained.
3. Check that ads are serving, that app-ads.txt is verified, and that analytics events arrive as expected.
4. Ship a small update with fixes quickly. A steady update rhythm signals an active app to both users and Google.

The checklist at a glance

• Developer account verified, team members added.
• Closed test running with enough engaged testers.
• Signed .aab, upload key backed up, current target API level.
• Privacy policy, Data safety, content rating and all App content declarations complete.
• Honest store listing with real screenshots and a working website.
• Staged rollout, vitals monitoring and a plan for the first update.