We have shipped apps to the Play Store as a small team, and the rejections we have seen were almost never about the app being bad. They were about paperwork, target versions and a keystore nobody wrote down.

Before you build: the boring part

Decide the application ID before the first upload, because it cannot change afterwards. Write the signing key down somewhere it will survive — a password manager, not a laptop that might die. Losing an upload key means a support ticket and a long wait, and in the worst case a new app listing.

Set the version code as something you can increment reliably. A build script that reads it from one file, rather than a number typed into a form each time, prevents the "version code already used" error that only appears when you are in a hurry.

Target SDK and policy changes

Google raises the required target SDK every year, and an app that was compliant in January can be blocked in August. Check the current requirement before you plan a release, not after. If your app has not been updated in two years, expect policy work as well as code work.

The listing is part of the product

The screenshots, the short description and the first two lines of the long description decide whether anyone installs. Do not use emulator screenshots with the debug banner, and do not describe features the app does not have — both get flagged.

Fill in the data safety form honestly. "No data collected" when you use an analytics SDK is the fastest way to a policy strike.

Permissions and privacy

Every permission you request needs a reason the user can see, and a privacy policy URL that actually loads. If your app handles photos or contacts, expect the reviewer to open it and try.

Testing tracks before production

Use internal testing for the first upload to shake out signing problems without burning a review cycle. Then closed testing with a handful of real devices, because the issues that matter — battery, notifications, back-button behaviour on one vendor's skin — never appear on an emulator.

The day of release

Roll out in stages rather than a full launch. A crash that hits two percent of users on a staged rollout is a fix; the same crash at full launch is a rating problem.

Keep the previous release ready to roll back, and watch the Android vitals screen for the first couple of days. It reports crashes and ANRs faster than reviews do.

After release

Write down what you learned, in the repo, next to the build script. The next release will be six months later and nobody will remember why the key store password is what it is.