The MVP Development Process, Step by Step: Idea to Post-Launch
The nine-stage mvp development process — from validating the business question to post-launch iteration, with the deliverable and duration for each stage.
Count the steps on five agency "our process" pages and you get five different numbers — six here, eight there, one that swears it is four. The work does not differ that much; the step count does, because a process page is a sales asset and the box count is set by how the vendor bills. Underneath the marketing, the mvp development process has a fixed sequence — and once you can name it, a padded quote and a quietly skipped stage both become obvious.
What follows is that sequence: nine stages, each with what it produces and how long it takes. It stays thin on mechanics — most stages are argued at length elsewhere in this cluster, and each links to the piece that owns it. For the engagement-level map, start with MVP development for startups.
What counts as a stage in a real MVP development process
Most "our process" pages describe generic software project management — discovery, design, development, testing, deployment — with the word MVP pasted on top. Those are not mvp development steps; they are the phases of any software project, which is why they are useless for auditing one. A stage belongs in a real mvp development process only if it passes three tests:
- It produces an artefact you can ask to see. A stage with no deliverable is a billing line.
- It is mobile-specific. If it reads identically for a web dashboard — no store submission, no IAP review, no privacy manifest — it was not written for your app.
- Skipping it has a distinct failure mode. "Worse quality" is not a failure mode. "The paywall only supports the provider you picked in week one" is.
The stages of MVP development below pass all three. Padded phases — the discovery workshop, the "future-proofing" sprint — do not.
The nine-stage MVP development process at a glance
The mvp development stages in order, with the deliverable that proves each happened:
| # | Stage | Deliverable | Typical duration |
|---|---|---|---|
| 1 | Business question | Question, metric, kill threshold | 3–10 days |
| 2 | Scope | Demo flow, cuts list, constraint sheet | 1–3 days |
| 3 | Architecture | Decisions: auth, payments, analytics, state | 2–4 days |
| 4 | Design | Production Figma, components and states | 1–2 weeks |
| 5 | Build | Weekly installable builds | 2–4 weeks AI-augmented; 4–6 production |
| 6 | Submission | Approved App Store / Play listing | 1–2 weeks |
| 7 | Stabilisation | Crash-free build, funnel you trust | 2–4 weeks |
| 8 | Handover | ADRs, README, CI/CD, runbook | 2–5 days |
| 9 | Measure and decide | Written answer to the stage-1 question | 30–90 days |
One caveat if your question is how long does MVP development take end to end: stages 3 and 4 overlap stage 5, so the calendar runs shorter than the column total. And most vendor pages describe MVP development from idea to launch and stop there — where the last three stages live.
Stages 1–3: everything before code
Stage 1. Validate the business question — before any vendor conversation
No vendor sells you this stage, because none can bill for it, and it is where the mvp development process actually starts. What happens: you write down the single business question the app exists to answer, the one metric that answers it, and the number that would make you stop. Deliverable: one page. Typical duration: three to ten days. Founder work, not engineering work.
The order matters because scope is derived from the question. Without one the vendor writes it for you, and vendors write questions that justify features. "Will 25% of users who finish onboarding still open the app in week three" gets you quoted a different app than a feature list does.
Two tells that stage 1 is not done. If you cannot name a result that would make you kill the app, you have a feature wish, not a business question — and a wish has no scope boundary. And if a landing page test or ten users served by hand would answer it, an MVP is a slow way to learn something you could know this week. In my experience a well-run stage 1 occasionally ends with the founder not hiring anyone — a successful outcome, and the cheapest line on this list.
Stage 2. Scope
What happens: the stage-1 question becomes a one-page demo flow — the exact screens and taps a first user sees — and the build list is derived backwards. Deliverable: demo flow, cuts list, constraint sheet a senior engineer can quote against. Typical duration: one focused sitting plus a day of revision. The exercise that produces those artefacts is how to scope a mobile MVP in 60 minutes, which owns this stage. How many features survive the cuts list is answered in full at how many features should an MVP have.
Stage 3. Architecture
What happens: the decisions expensive to reverse get made and written down — auth and identity, payment provider abstraction, analytics event taxonomy, state management pattern. Deliverable: a short written decision per area, not a diagram. Typical duration: two to four days, usually running into the first build week. The eight-area map for non-engineers is mobile app architecture for founders; the event-naming half is the analytics event taxonomy your MVP needs.
Stages 4–6: design, build, submit
Stage 4. Design and build-ready assets
What happens: the demo flow becomes production-grade Figma — components, tokens, empty and error states — plus the store asset list. Deliverable: a file an engineer can build from without guessing at empty states. Typical duration: one to two weeks, overlapping stage 3. If design is still iterating in build week two, the stage-5 timeline does not hold.
Stage 5. Build
What happens: screens, integrations, paywall, analytics wiring, weekly builds. Deliverable: an app the founder opens on their own phone every week. Typical duration: two to four weeks for a senior-led AI-augmented MVP, four to six for a production-grade version — which holds only when stage 4 is done, one person decides, and the backend already exists.
Boyfi is what the compressed end of the mvp development process looks like: live on the App Store and Google Play six weeks after kickoff, two subscription paths in parallel — AI-augmented delivery on top of stage 3, not instead of it. For the week-by-week founder playbook, see mobile app development for startups.
Stage 6. Store submission
What happens: privacy manifests, listings, screenshots, age rating, IAP and sandbox testing, submission, review. Deliverable: an approved listing on each store. Typical duration: one to two weeks; plan for one rejection on a first submission. RoomFlash shipped against a fixed date tied to an industry event and still passed on the first submission — under a hard deadline the stages compress, they do not get dropped. The night-before list is the mobile MVP launch checklist for founders.
Stages 7–9: the half of the MVP development process after launch
Stage 7. Stabilisation
What happens: a week of real installs turns up what the beta group never triggered — a crash on a device nobody tested, a paywall edge case, an event firing twice and skewing the funnel. Deliverable: a crash-free rate you would defend to an investor, and a funnel you trust. Typical duration: two to four weeks, same senior engineer still on the project. RoomFlash came through that window with zero critical issues; an engagement whose timeline ends on the launch date has no stage 7.
Stage 8. Handover
What happens: the codebase is made transferable — architecture decision records, a README that takes a new engineer from clone to running app in thirty minutes, signed CI/CD, a runbook. Deliverable: those four artefacts, on request. Typical duration: two to five days if written along the way, weeks if reconstructed. If who runs these stages is still an open question, see agency vs freelance developer.
Stage 9. Measure against the question, then decide what the MVP proved
This stage closes the mvp development lifecycle, and it is the one most often missing. What happens: you read the real number against the threshold you set in stage 1, before you had a stake in the answer. Deliverable: a written answer — yes, no, or not cleanly — and the decision that follows. Typical duration: thirty to ninety days of usage.
- Answered yes. You are no longer building an MVP. Scope and price the next build as a full product, not as "MVP phase two" — the label that quietly ships a full product at MVP quality.
- Answered no. Rerun stage 1 with what you learned. Adding features to an app that failed its own test is paying to postpone the answer.
- Not answered cleanly. Usually because the MVP chased two questions at once, so a soft signal on one gets explained away by the other.
The common failure is not deciding wrong — it is never running the stage: the app ships, the team rolls into a feature backlog, and momentum makes the decision. For the four signals that the MVP phase is over, see when to build MVP vs full product.
How to use the MVP development process as an audit checklist
Read backwards, the nine stages become an mvp process checklist for whatever is in front of you.
Against a quote: map every line item to a stage number. The stages with no line item are being skipped, and two go missing more often than the rest. A quote that opens with a feature list instead of a business question has no stage 1 — nobody set the target, so the vendor invents one, usually a feature-shaped one. A quote silent on what happens ninety days after launch has no stage 9 — the engagement ends the moment building does, before anyone reads the number.
Against a live engagement: ask which stage you are in and what its deliverable is. Both answers should come back in one sentence. If nobody can name the stage or its artefact, you are between stages — where weeks disappear unnoticed.
The rewrites I get called in for almost never trace back to a missing feature — they trace back to a stage nobody ran, usually one nobody could have named three weeks earlier. For the stages played out across four shipped apps, see minimum viable product examples.
What "on track" actually looks like
You do not need to be technical to audit an MVP build. You need to name the stage you are in, the artefact it produces, and the date it lands — and notice when two weeks pass without the three changing. That is what a fixed mvp development process buys you.
If you want a second opinion on which stage your project is in, tell me about your project — or see the MVP development engagement model.