Six to ten weeks from a signed scope to an app in the store sounds fast. It is, and it is also realistic, as long as the first version is designed to be a first version. Most projects that drag on for months do so because they try to launch the third version first.
This is how that timeline actually works, and what comes after it.
Decide what the first version is for
A minimum viable product is not a cheaper, worse version of your full idea. It is the smallest product that can answer your most important question: will people use this, come back to it and, eventually, pay for it?
That changes how you cut scope. Instead of asking "what can we remove?", ask "what is the one journey a user must be able to complete?". For a booking app it is finding a slot and booking it. For a game it is the core loop being fun twice in a row. Everything that does not serve that journey waits for version two:
- Admin dashboards can often start as a simple internal tool or a spreadsheet.
- Five sign-in options can start as two.
- Settings screens, themes and edge-case features can wait for real user feedback.
A good test: if a feature would not change whether someone uses the app tomorrow, it does not belong in the first release.
The timeline, week by week
Week 0: intro call
Thirty minutes to understand the idea, the users and the constraints, and to be honest about fit. Some projects are better served by a different approach or a different team.
Week 1: a fixed, written scope
A document that lists exactly what the first version does, which platforms it runs on, what is explicitly out of scope, and a fixed price. This is the most valuable week of the project. Every hour spent here saves several later.
Weeks 2–3: design
User flows, then a clickable prototype you can open on your own phone. Changing a screen in a prototype costs minutes. Changing it after it is built costs days. This is where you should be at your most demanding.
Weeks 4–9: build
The app and its backend are built in weekly increments, and every week you get a new build to install: TestFlight on iPhone, a test track on Android. You watch the product grow, not a progress report. Small adjustments happen along the way. Large new ideas go on the list for version two, so the date holds.
Launch
Store listings, screenshots and privacy answers are prepared, the app is submitted for review, and it goes live under your own developer accounts.
What the stores check before you go live
Apple and Google both review apps before publishing them, and both reject apps for reasons that are entirely avoidable if you know them in advance. A few that catch first launches:
- Privacy declarations. Apple's App Privacy section and Google Play's Data safety form must match what the app and every SDK inside it actually collect, including analytics and ads.
- Account deletion. If users can create an account in your app, Apple requires that they can also start deleting it from inside the app, and Google Play asks for a web link where deletion can be requested.
- Digital purchases. Digital goods and subscriptions sold inside the app generally have to go through the store's own in-app purchase system.
- Completeness. Placeholder content, broken links, demo accounts that do not work or features that need a login the reviewer was not given are common reasons for rejection.
- Google Play testing for new accounts. At the time of writing, newly created personal developer accounts must run a closed test with at least 12 testers for 14 days before they can publish to production. Plan it into the schedule.
Apple's review often comes back within a day or two. A rejection is not a disaster, it is a message: you answer, fix and resubmit. Knowing the rules up front simply means it rarely comes to that.
After launch: the work that keeps an app alive
Launch day is the start of the most informative period in your app's life. For the first time you see what real people do, not what you assumed they would do. The work that follows is what separates apps that grow from apps that quietly fade:
- Crash and performance monitoring. Real devices and real networks find problems no test suite does. The first weeks usually bring a round of quick fixes.
- Reading reviews and analytics. Where do people stop? What do they ask for? This is the raw material for version two.
- Store optimisation. The listing's title, subtitle, screenshots and localisation decide how many people who find the app actually install it.
- Yearly platform changes. Apple raises the SDK version new submissions must be built with, and Google Play requires apps to target a recent Android version to keep publishing updates. An app nobody touches for a year can find itself unable to ship a fix.
- Revenue plumbing. In-app purchases, subscriptions and ads each need ongoing care: price tests, new products, policy changes from the networks.
Why we stay on after launch
We learned all of this on our own apps first. Vokap went through App Review, store listings in 27 languages, rewarded ads verified on the server and over-the-air updates long before we offered any of it to a client. That is why our projects do not end at "submitted": we handle the review, stay on for the first updates, and offer a monthly retainer for teams who want the app looked after properly without hiring for it.
If you have an idea that fits a first version like the one described here, the quickest way to find out what it would take is to send us a brief. If you are still choosing who should build it, read studio, freelancer or in-house first.