I've taken apps from a founder's first message to live store listings enough times now — six-plus of them currently live between Google Play and the App Store — that the path has stopped looking mysterious and started looking like a repeatable process. This is that process, end to end, including the unglamorous store-operations half that most "how to build an MVP" posts skip entirely.
The headline lesson first: the code is usually the most predictable part. Scope decisions sink timelines at the start; store operations sink them at the end. Get those two right and the middle mostly takes care of itself.
Phase 1 — Scope: find the one loop that matters (week 1)
Every product idea arrives as a feature list. The first working session is about deleting most of it. My tool for this is a single question:
What is the one loop a user repeats that delivers the core value?
For a quiz app I shipped, the loop was pick topic → take quiz → see progress. Not the achievements ladder, not the subscription tiers, not push re-engagement — those all exist now, but v1's job was proving people would run that loop repeatedly. For an AI planner, the loop was check in → get plan → complete items. One loop, stated in one sentence, is the MVP's definition of done.
Everything else gets sorted into three buckets: required for the loop, required for launch (auth, privacy policy, the boring survival kit), and after we have users. Founders rarely enjoy this meeting. Every founder has thanked me for it later.
Two scope rules that pay for themselves:
- Auth is not optional to design, even if it's deferred. Retrofitting accounts onto anonymous data is a migration project. Decide the identity story now, even if v1 ships guest-only.
- Anything with store review implications — payments, health claims, user-generated content — gets flagged in week 1, because it shapes both architecture and the review strategy months later.
Phase 2 — Design: flows before pixels (weeks 1–2)
I design the loop as screens with states before anything is polished: every screen in loading, empty, error, and full-data form. Empty states are where MVPs are actually experienced — every user starts with no data — and they're the states founders never think to specify.
Visual polish gets concentrated where it compounds: the two or three screens in the core loop that users see fifty times, and onboarding, which they see once but judge you by. Settings screens do not need art direction in v1.
Phase 3 — Build: walking skeleton first (weeks 2–8)
The single most useful engineering habit for MVPs: build a walking skeleton — the thinnest possible end-to-end slice — in the first days. Real app, real backend, real auth, one screen, deployed to a test track on real devices. It does almost nothing, but it does it through every layer of the stack.
Why this beats building feature-by-feature-then-integrating:
- Integration risk dies in week 2 instead of week 7. Signing, backend connectivity, store test tracks — all the things that "should just work" get their surprises out early.
- The founder sees the app on their phone almost immediately, which transforms the feedback loop from slideware to reality.
- Every feature after that lands on proven rails.
From the skeleton onward: features in vertical slices in priority order, on the architecture I've described in Riverpod architecture for MVPs that scale, with a build going to the founder's device every week without exception. A weekly build is project management, honesty mechanism, and morale engine in one artifact.
Phase 4 — Store operations: start three weeks before you think you need to (weeks 6–9)
Here is where first-time founders lose whole weeks, because none of this is engineering and all of it gates launch:
- Accounts take time. Play Console and App Store Connect enrolment — especially company accounts with verification — can take days to weeks. Open them the moment the project starts, not when the build is ready.
- Google requires closed testing before production for new personal accounts — a real tester group over a sustained window. That's calendar time no amount of coding compresses. Plan it in.
- The listing is a mini-project: screenshots per device class, descriptions, privacy policy URL, data-safety declarations. I prepare it in parallel with the final build weeks.
- Review rejections are normal. Apple in particular will bounce things — login demos missing, background permissions under-explained, payment wording. A rejection is a 1–3 day feedback loop, so the schedule assumes at least one round trip. First-app founders read a rejection as catastrophe; it's Tuesday.
My rule of thumb: store operations are three weeks of calendar time, partially parallel to development — and they're on the critical path from day one.
Phase 5 — Launch is a rollout, not a moment
I never ship v1 to 100% of the world at once. Staged rollout on Play, phased release on iOS, watching crash-free rates and the funnel around the core loop before widening. The first week after launch is scheduled work — a triage build ships within days, because real devices and real users always find something.
And then the real milestone: watching whether users run the loop from Phase 1. That number — not the launch tweet — tells you what v2 should be.
The honest timeline
For a well-scoped MVP with a committed founder: 8–12 weeks from first call to live on both stores. Faster is possible when scope is brutal; slower is guaranteed when Phase 1 is skipped. If someone quotes you four weeks to both stores for a novel product, one of three things is true: the scope is tiny, the store phase is missing from the plan, or the plan is fiction.
The founders who ship well aren't the ones with the biggest feature lists. They're the ones who pick a loop, protect it ruthlessly, and treat the stores as part of the product — not an afterthought at the finish line.