Step by step
Getting an Android app onto Google Play is a fixed sequence: a developer account, a store listing, an uploaded build, the policy declarations, and a release you promote rather than re-upload. Here is that sequence in the order Play Console asks for it, and where the 12-tester closed testing step sits inside it.
Play Console does not enforce an order the way a printed checklist would, which is why the same mistakes get made twice. The sequence that works is: create the developer account, create the app entry, upload a build to internal testing, complete the store listing and the policy declarations, release to closed testing, run the required window, then apply for production access and promote the tested release.
Two of those steps cost real time rather than effort. The closed testing window is a fixed number of days you cannot shorten, and the production access review is a queue you cannot escalate. Everything else is hours of work. The mistake that costs the most is uploading a fresh build to production after the testing is done, because that throws away the one thing the testing established — that the version shipping is the version that was tested.
The first decision is the account type, because it changes both the cost and whether the closed testing step applies to you at all. A personal account is the quick route: a one-off registration fee, an identity check, and no further requirements. An organisation account needs organisation details and a D-U-N-S number, which takes days to obtain, and in exchange it is exempt from the mandatory closed testing step.
Register a personal account unless you genuinely need an organisation account. The testing requirement applies to new personal accounts, so a personal account means planning for the tester window, while an organisation account means planning for a D-U-N-S number and then a review instead. Neither path avoids work. They avoid different work, and the one you pick determines which of them sits on your critical path.
The store listing is where most first submissions stall, because several fields that look optional are not. You need an app name, a short description, a full description, an icon, a feature graphic, a category, a contact email, and a privacy policy URL. Screenshots are required, at minimum for phones, and review checks them against what the app actually does — a listing advertising a video player with screenshots of a recipe app gets rejected on accuracy rather than quality.
Write the short description for someone who has not opened the link yet. It appears under the title in search results and it is often the only text a person reads before deciding whether to install. The full description can be long, but only its first lines appear before the see more link, so put the value there rather than the boilerplate. Lead with what the app does for the user, not with a list of features.
Google Play distributes Android app bundles rather than APKs, so what you upload is a bundle generated by Android Studio or by the bundletool command line. The bundle carries a version code that has to increase with every upload, and a signature that Play App Signing will manage for you once you enrol. Enrolling immediately is worth the minute it takes: without it you remain the only holder of the key that signs every future update, and a lost upload key ends your ability to update the app.
The target API level matters too. Play Store requires new apps and updates to target a recent Android API level, and the bar moves over time. An app targeting an old level can still be uploaded, which is what makes this a slow failure: nothing happens until the day you most need to ship a fix and the update is rejected for targeting too low.
Three separate forms gate publication and each one is easy to get subtly wrong. The content rating questionnaire produces a rating that has to match what the app contains. The data safety form declares what the app collects and whether it is shared, and it is compared against the permissions the app actually requests — a mismatch here is one of the most common rejection reasons. The target audience and content declaration determines which policies apply, including whether the app is available to children and what that obliges you to do.
All three are quick if you answer them accurately and slow if you guess. The data safety form is easiest to complete by reading your own permission list and being honest about each entry. Declaring less than you actually collect is not the safe choice; it is precisely the mismatch that gets caught during review.
Internal testing is the fast lane for confirming a build installs, launches and does not immediately crash, and a release there is available to testers within minutes. It is not the same thing as closed testing: internal testers are email addresses you added yourself, they do not opt in through a link, and the track does not satisfy the requirement. The requirement is met in a closed testing track, where testers join through an opt-in link and remain opted in for the stated period.
The sequence that works is to use internal testing until the build is stable, then promote that same build to a closed testing track, run the window, and afterwards promote the tested release to production. Promotion rather than re-upload is the detail that matters, because it keeps the version history attached to the build that was tested. If you make a fix during the window, ship it into the same closed track and let the period continue rather than starting a new one.
When you promote a release to production you choose whether it reaches everyone immediately or a percentage of devices first. A staged rollout is the sensible default for a first release: it limits the blast radius if something is wrong, and Play Console will halt the rollout on its own when it detects a rise in crashes. You raise the percentage once the numbers hold rather than gambling the launch on one build being flawless.
Your first update is a good moment to learn how the process feels, because it is only a version code increase, a bundle upload and a release to production. Later updates do not repeat the closed testing requirement. Knowing that removes a lot of the hesitation from shipping a fix days after launch, when the temptation is to sit on a known problem.
Rejection is common on first submissions and the message is specific, which is the useful part. Read it precisely rather than inferring a cause: most rejections name a listing deficiency, a policy issue or a build problem, and each has a different fix. Resubmitting an unchanged listing is the one approach that never works, because the same evidence gets examined again and the account now carries a recorded rejection.
Fix what is named, resubmit, and expect the second review to be faster because the app has a history. Keep the rejected release in place rather than deleting it, and write down what you changed so the next submission does not reintroduce the same problem. Most first rejections are about the listing or the declarations rather than the build, which is why finishing those before you submit is the cheapest insurance available.
Publishing costs a one-off developer account registration fee, which varies by region and is not charged again each year. There is no charge for uploading builds or for submitting for review. Selling anything inside the app is separate from the cost of publishing it.
A complete roster assigned within hours, held for the full window, so the 14 days are the only thing between you and a submission.