How to launch an app
The sequence from idea to both stores: what matters, what can wait, and where launches fail.
Scope the first version as the smallest thing worth downloading, build on one codebase for both platforms unless device features demand native, design for store review requirements upfront, and open the developer accounts in your own name. Plan distribution before launch, not after.
Is it a fit?
Reason
One thing the app does better than a website. Without it the website is cheaper.
Review
Both stores review it, and most rejections are for things known in advance.
Accounts
You hold the store accounts and the code, not the person who built it.
Start here. You get back the point where building stops costing more than buying something that exists.
When building paysWork it out in a minute
Four numbers and one question about fit. Gives you the answer and what it is worth.
The plan
Do these six, in order
A time against each one and a way to tell it is finished.
Cut the feature list to day one
What the first user needs, and nothing after that.
half a day · Done when the list fits on one screen
Draw the three flows
Start to finish, before anyone designs a screen.
1 day · Done when each path has a defined end state
Choose one codebase for both stores
Write down the choice and the reason.
2 hours · Done when the reason is on paper
Design for store review from day one
Read the rejection reasons for your category first.
half a day · Done when a submission checklist exists
Instrument before the listing goes up
Install, first action, return visit.
1 day · Done when the three events show from a test device
Ship small, fix, then announce
A small group first. Loud comes after it holds.
2 weeks · Done when crash-free sessions hold for a week
Most first apps are too big. Not badly built, too big. Scope grows during the excitement of planning, and the cost shows up later as a longer build, a harder review, and a launch nobody has energy left to promote.
The sequence below is biased toward getting something real in front of real users early.
01.Cut the scope in half
Take the feature list and remove half of it. Then look again. The version that ships should do one thing completely rather than six things partially, because users judge an app on whether its core job works, not on how much it contains.
Everything cut goes on a list for version two, which makes cutting feel like sequencing rather than loss.
02.Design the flows before the screens
Map the journeys before anyone designs a screen. What happens on first open, what the empty state says, what an error looks like, what happens with no connection, how someone recovers an account.
These unglamorous states are where most apps feel broken.
03.Build once for both stores
Unless you have a specific reason to go native, build once and ship to both stores. The tooling is mature, and the money saved goes into the parts users notice: speed, polish, and the second version.
Go native when the app depends heavily on device hardware, needs the highest possible graphics performance.
Twenty minutes with a practitioner from our team, and you leave with a plan for your specific situation.
Talk to an expert04.Plan store review from day one
Review is a process to prepare for, not a formality at the end. Accounts, privacy declarations, data disclosures, test credentials for reviewers, and a working demo path all need to exist before submission.
Most rejections are procedural rather than qualitative: a missing privacy label, a login the reviewer cannot get past.
05.Instrument before launch
Add analytics before launch, not after. Without them you will have opinions about why people leave and no evidence. At minimum: install, first open, activation, the core action, and retention at day one, seven and thirty.
Also add crash reporting from day one.
06.Launch small, then loud
Launch to a small group first. Friendly users, a beta cohort, one segment. Let them find the obvious problems while the audience is small enough that the fixes are quiet and the reviews are forgiving.
Most launches go better when MVP development came first and the list was short.
Then push properly once retention holds.
Adding features mid-build; every addition moves the date.
Skipping the reviewer demo account; instant rejection.
Treating launch day as the finish line; it is the starting line for reviews, updates, and rankings.
Questions we get
The ones that come up on almost every call.
How long does it take to build an app?
A focused first version is typically three to five months including store review.
Native or cross-platform?
Cross-platform for the large majority of business apps.
Why do apps get rejected from the stores?
Overwhelmingly for procedural reasons: incomplete privacy disclosures, a login reviewers cannot pass, subscriptions that do not restore.
Should we launch on both stores at once?
Usually yes, unless your audience is clearly concentrated on one.
Most of this is doable in house.
Your results so far
Kept in this browser, sent nowhere.
By Shaheer Shaikh, technology and operations consultant · Updated October 3, 2026
Read next
The service behind this guide, the questions people ask, and the next thing worth reading.
Shaheer leads the work, with engineers, writers, filers and analysts behind him. C-suite operations for a San Francisco AI company, Six Sigma on the process side, Anthropic certified on the Model Context Protocol, ten years across eight industries. See what we have built