Release strategy: staged, not all at once
The word "launch" sounds like it describes a single day, but in practice it is a multi-stage process. The reason is simple: the rating your app earns in its first days stays with you for a long time and is very hard to undo.
Both stores give you tools for a staged release:
Apple — TestFlight. You distribute the build to testers without publishing to the store, they send feedback, you fix things.
Google Play — testing tracks. Per Google's documentation there are three: - Internal testing — up to 100 chosen testers - Closed testing — a limited number of chosen testers - Open testing — users can join directly from your store listing
And Production — all users in the countries you choose.
Remember: for personal Play accounts created after 13 November 2023 a closed test is mandatory — 12 testers, 14 days.
| Stage | Who sees it | What you learn here |
|---|---|---|
| Internal / TestFlight | You and 5-20 people you know | Does it open? Does it crash? Is it understandable? |
| Closed testing | 12-100 invited people (may be mandatory on Play) | Does someone who does not know you get through onboarding? |
| Soft launch — a small market | Everyone in one or two countries | What does real store traffic show? Conversion, D1 retention |
| Production — full | All target countries | What happens at scale |
What a soft launch is and why it matters. A soft launch means publishing first in a small, cheap market. The goal is not sales but learning: you see conversion rate, D1 retention and crash frequency on real users.
For someone working from Azerbaijan the practical choice: publish first for Azerbaijan (or Azerbaijan plus Georgia), watch the numbers for two to three weeks, then widen the market.
The biggest benefit is protecting your rating. If there is a serious problem in onboarding, finding it on 50 users is far cheaper than finding it on 5000 — because by 5000 there are already dozens of one-star reviews.
Staged rollout. On the Play side you can release an update to a fraction of users first. If the new version crashes, this contains the damage. Apple offers phased release as well.
The most common surprise with vibe-coded apps is this: the app works on your phone. This is exactly where the testing stage earns its keep — on another device, another OS version, a weak connection, in the hands of someone opening it for the first time, the app can behave completely differently.
Practice. Write your own release plan: how many people at each stage, for how long, and which number you will look at before moving on. Done means: you have written one "gate condition" per stage — for example "I move to production if D1 retention is above 25%".
📚 Sources and documentation
- Prepare and roll out a releaseofficialsupport.google.com
The internal (up to 100 testers), closed and open tracks, and production.
- TestFlightofficialdeveloper.apple.com
Testing a build on the Apple side without publishing to the store.
- App testing requirements for new personal developer accountsofficialsupport.google.com
The 12-tester, 14-day rule — build your plan around this condition.
- Prepare your app for reviewofficialsupport.google.com
The checklist Play requires before publishing.