The Zero-to-App-Store Timeline: 14 Weeks, Week by Week, and the Founder Decisions on Days 3, 19, and 62

Why 14 weeks, and what the number actually covers

Fourteen weeks is the span from kickoff to a public App Store and Google Play listing for a single-audience mobile app with a custom backend, a back office for staff, and no third-party integrations beyond payments and push. It covers discovery, backend, app, two review cycles, and store approval. It does not cover a second app for a second audience.

The number comes from real builds, not an estimating template. The MOVE & MEET React Native app went from spreadsheet-run operations to a shipped iOS and Android app in that window. The Plodovi driver app taught us where the same calendar stretches: multi-audience products, regulated payment flows, and anything requiring a partner's sandbox access add weeks that have nothing to do with how fast anyone writes code.

The useful thing about fixing the number is that it forces the conversation about what fits. Fourteen weeks buys one primary user journey done properly, one admin surface to operate it, and enough analytics to know whether the thing works. Everything else is a version 1.1 conversation, and it is far better to have that conversation in week two than in week eleven.

• • Weeks 1 to 2: discovery, entity and event model, must-ship-first list, non-goals document, design direction
• • Weeks 3 to 5: backend and data model, auth, admin panel skeleton, seeded staging data
• • Weeks 6 to 9: app screens against a real backend, offline and error states, push and deep-link plumbing
• • Week 10: internal build, first TestFlight and internal Google Play track
• • Weeks 11 to 12: real-user beta, bug triage, store listing assets, privacy declarations
• • Week 13: submission, rejection handling, resubmission
• • Week 14: approval, phased rollout, monitoring, handover

Day 3: the Apple Developer account and legal entity decision

Day 3 is when the founder has to commit to which legal entity owns the Apple Developer and Google Play accounts, and start the enrolment. An Apple Developer Program organisation enrolment needs a legally registered entity and a D-U-N-S number, and that verification chain can take days or weeks. Nothing about it is under an engineering team's control.

This is the single most common cause of a delayed launch on an otherwise on-schedule build. The code was ready in week 10 and the account was still in verification. Enrolling as an individual is faster, but the app then ships under a person's name rather than a company name, and moving a published app between accounts later is a manual transfer process with its own conditions. Founders who plan to raise money, sell the company, or simply look like a business should enrol as an organisation and start on day 3.

The same day covers three adjacent items that are easy to defer and painful to defer: who owns the app's bundle identifier and package name (choose it once, it is permanent), which email domain receives store and crash notifications, and whether a company bank account exists that can receive App Store payouts if the app charges money. We ask for account admin access, not the founder's personal credentials, and we hand that access back untouched at handover.

• • Legal entity confirmed and D-U-N-S number requested or verified
• • Apple Developer Program organisation enrolment started, Google Play Console account created
• • Bundle ID and Android package name chosen and frozen
• • Shared company email or alias for all store and monitoring notifications
• • Payout bank details if the app transacts

Weeks 1 to 5: discovery, then the backend that has to exist before anything can be demoed

The first five weeks produce no installable app, and that is correct. Weeks 1 and 2 produce an entity and event model, a must-ship-first list, and a written non-goals list. Weeks 3 to 5 build the backend, auth, and admin panel, because a mobile app with no backend cannot be demonstrated to anyone in a way that means anything.

Founders consistently underestimate this part, because the visible artefact of a mobile project is the app. But the app is a client. If sessions, bookings, orders, or deliveries do not exist as real records with real state transitions, the screens are a slideshow. On the MOVE & MEET build, the back office had to exist before the app, because the people running the business needed somewhere to create the sessions the app would display. The same held for Plodovi, where the driver app is meaningless without an order and route model behind it.

The practical consequence is that the first thing a founder can actually click is usually the admin panel, not the app, and it arrives around week 4. We push clients to use it for real: create the real sessions, the real product list, the real driver roster. Every fake demo record is a bug you will find in week 12 instead of week 5.

Day 19: push notifications, deep links, and the decisions that are expensive to reverse after launch

Around day 19, with the data model settled and the app shell starting, three infrastructure choices get locked: the push notification provider and token model, the deep-link scheme and universal-link domain, and the analytics and crash-reporting stack. All three are cheap to decide now and disruptive to change once real users have installed the app.

Push is the sharpest example. Once users have granted notification permission and their device tokens live in your database against a specific provider, migrating providers means re-registering every device, and any user who does not open the app during the migration window silently stops receiving notifications. iOS also gives you exactly one shot at the permission prompt per install: if you fire it on first launch before the user understands what notifications are for, a meaningful share of your audience declines permanently and can only be recovered by walking them into system settings. We ask for the prompt to be triggered by an action that earns it, such as after a first booking or a first order.

Deep links are the second. Choosing a custom URL scheme only, rather than configuring universal links and Android App Links against a domain you control, means every marketing email, shared session link, and referral message that arrives before the app is installed dead-ends. Retrofitting universal links is technically possible but requires domain association files, app-side entitlements, and a new store release, and every link you already sent stays broken. The third, analytics, is less irreversible but historically painful: you cannot backfill events you never sent, so if there is a metric the founder will be judged on, it must be instrumented before beta, not after launch.

• • Push provider and device-token storage model, plus when the permission prompt fires
• • Universal links and Android App Links on a domain you own, not just a custom scheme
• • Analytics event names and the three metrics that define success, instrumented before beta
• • Crash reporting wired to a shared company account, not an engineer's personal one
• • Authentication method, because migrating identity providers after launch means a forced re-login for everyone

Weeks 10 to 12: TestFlight, the beta, and when store assets must be final

The first TestFlight build goes out in week 10. Store listing assets, screenshots, description, keywords, privacy policy URL, support URL, and the App Privacy data-collection declarations, must be final by the end of week 12, roughly three to five days before submission. They are not a launch-day task, and they are not something an engineering team can write on the founder's behalf.

TestFlight itself has a gate people forget: builds distributed to external testers go through Apple's beta app review, which is lighter than full review but still a queue and still capable of rejecting you. Internal testers on the account skip it. So week 10 is internal only, and the external beta cohort starts a couple of days later once the beta review clears. Google Play's internal testing track has no equivalent human review, which is why the Android build almost always reaches testers first and why founders wrongly conclude iOS is running late.

Weeks 11 and 12 are the least glamorous and most valuable weeks of the project. Real users on real devices on real networks find the things a simulator never will: expired sessions after a phone sits overnight, permission dialogs on Android versions nobody on the team owns, payment sheets behaving differently on older iOS. We triage the beta findings into must-fix-before-submission, fix-in-1.0.1, and won't-fix, and we make the founder sign off on that split rather than deciding it privately.

Day 62 and week 13: the submission decision, the rejections we actually hit, and what got cut

Day 62, roughly the start of week 10, is the scope-freeze decision: the founder confirms the final v1.0 feature list and everything else moves to a written 1.1 list. Week 13 is submission. Budget for at least one rejection. First review responses typically arrive within a day or two, but each rejection cycle costs two to four calendar days including the fix.

The rejection reasons we have actually hit are boringly consistent, and none of them were about code quality. Incomplete or inaccurate App Privacy declarations against what the SDKs actually collect. Sign in with Apple missing when third-party social login is offered. Demo credentials that the reviewer could not use, either expired or pointing at an empty account with nothing to review. A support URL that resolved to a page with no actual contact route. Each of these is fixable in hours, but the resubmission puts you back in the queue, which is why the honest calendar contains a rejection rather than pretending it will not happen.

The cut lists across these builds rhyme. What shipped in v1.0: the core booking or ordering flow, auth, push notifications, payment, a profile, and the admin surface behind it. What got cut to 1.1 or later: in-app chat, social feeds and comment threads, referral and loyalty mechanics, deep analytics dashboards for end users, dark mode, tablet layouts, and every settings toggle nobody had asked for yet. Cutting these is not a failure of ambition. Shipping a smaller thing in week 14 gives you real users generating real evidence about which of the cut items actually matters, and in our experience at least a third of any 1.1 list quietly dies once that evidence exists.

• • Day 62: v1.0 scope freeze, signed off in writing, everything else onto a dated 1.1 list
• • Week 13 day 1: submission with working demo credentials and a reviewer note explaining the flow
• • Week 13: expect one rejection cycle, two to four days including fix and requeue
• • Week 14: approval, phased release on iOS and staged rollout on Google Play, crash and funnel monitoring for the first 72 hours
• • Week 14 end: repository, store accounts, and infrastructure access handed to the client

For the engineering-side view of the same calendar, see our MOVE & MEET 14-week build log, which covers the feature order, scope cuts, and TestFlight builds week by week.