The short answer
For a well-scoped product with one core job, a realistic MVP timeline is 8 to 12 weeks from the first call to real users: one week of discovery, two of design, five to seven of building, and one to two to launch and stabilise. Simpler products can land in six weeks; add AI, payments or a marketplace and the honest number moves toward twelve. Anyone quoting three weeks is describing a prototype, and anyone quoting six months is describing a first version that has not been scoped yet.
Week by week
Week 1: discovery
The product is defined on paper before anything is built: the one job it does, who pays for it, the smallest version that proves it, and what gets measured after launch. This week ends with a fixed scope and a fixed price. Skipping it does not save a week; it moves the arguing to week six, where it costs more.
Weeks 2 to 3: design
Flows first, then screens, then a clickable prototype you can put in front of five potential users. Changing a screen in a design tool costs minutes; changing it in code costs days. This is also when the visual identity is settled so the launch does not look like a demo.
Weeks 4 to 9: build
The product is built in weekly slices, each ending in a demo of working software, not a status report. The order matters: the riskiest piece first, whether that is the AI feature, the payment flow or the integration nobody has documentation for. Sign-in, payments, notifications and the admin panel are unglamorous and non-negotiable; they are the difference between an MVP and a prototype.
If the product has an AI feature, the first fortnight of the build includes a prototype on real data measured against a test set, so a weak feature is caught while it is still cheap to change course. How that works is on our AI MVP development page.
Weeks 10 to 12: launch and learn
Store review (allow up to a week for Apple), analytics wired to the questions that matter, the first users onboarded, and a list of what they actually did versus what everyone assumed. The first iteration after launch belongs inside the project, because the day after launch is when the real information arrives.
What makes timelines slip
- Undecided decisions. The single biggest cause. Every "we will decide later" becomes a blocked week.
- Feature growth. The second biggest. The discipline is not saying no forever; it is saying "version two".
- Third parties. App store review, payment gateway approval, API access from a partner: none of these move on your schedule, so they start early.
- One shared person. If the founder who approves everything is available one evening a week, the calendar belongs to them, not the team.
How to make it faster without making it worse
Cut scope, not steps. A six-week MVP with discovery, design and a real launch beats a six-week build that skipped straight to code. Choose one platform, or use Flutter or React Native to get both from one codebase, as covered in Flutter vs React Native vs native. Reuse solved problems: sign-in, payments, chat and analytics are services, not features to build.