A focused MVP takes 8 to 12 weeks with an experienced team: one platform, one core flow, sign-in, payments if you charge, and an admin view. Simpler validation builds land in 4 to 6 weeks; anything quoted beyond 16 weeks is no longer an MVP, it is a product wearing the name for budget reasons.
Here is the quick-answer table, then the part estimates never show you: where the weeks actually go, week by week, and what quietly adds a month.
| What you are building | Realistic timeline | Example |
|---|---|---|
| Landing page plus a manual back end | 2 to 3 weeks | Taking orders by form, fulfilling by hand to test demand |
| Single-flow web app | 4 to 6 weeks | One user type, one core action, no payments |
| Standard MVP | 8 to 12 weeks | Accounts, payments, core flow, admin panel, one platform |
| MVP with AI features | 8 to 14 weeks | The above plus retrieval, evaluation sets and model integration |
| Two-sided marketplace MVP | 12 to 16 weeks | Two user types, matching, payments and payouts |
Week by week: where a 10-week MVP actually goes
This is the shape of a standard build at our studio, not a theoretical model. Weeks overlap in practice; the sequence of decisions does not.
Weeks 1 to 2: decisions. Discovery, flows and wireframes, then screens. This fortnight exists to make changes while they cost an hour instead of a week; every structural argument we can finish in Figma is a week not lost in code. The single most useful thing a founder does all project happens here: cutting the feature list.
Weeks 3 to 8: the build. Accounts and sign-in first, because everything hangs off them, then the core flow, then payments and the third-party integrations, then the admin panel. From week four you are using a running product weekly, not watching slides. Integrations are the recurring surprise: connecting a payment gateway, a courier API or WhatsApp is days when the account, documents and approvals are ready, and weeks when they are not.
Weeks 9 to 10: the unglamorous part. Error states, slow-connection behaviour, testing on real phones, store submission if there is an app. App Store review adds days and occasionally a rejection cycle; we submit early builds precisely so the first rejection happens on a build that does not matter.
Where the effort lands across those ten weeks, roughly: a fifth on design and decisions, half on the build itself, and the rest on integrations, testing and launch. Founders consistently over-imagine the build and under-imagine the edges.
What actually stretches a timeline
Competitor articles list "scope creep" and move on. Having built MVPs for eight years, here is the honest ranking.
1. Decision latency, which means you. The largest single variable in our records is not engineering speed; it is how long decisions wait. A team that answers questions in hours ships in ten weeks. A team where every screen waits four days for sign-off ships the same product in sixteen. Agree at kickoff who decides, and give that person the calendar space to decide daily.
2. The second user type. "Customers and vendors" is not one MVP, it is nearly two: two onboardings, two dashboards, two permission models. The marketplace row in the table above is higher for exactly this reason, and the cheapest fix is launching with one side manual, which most successful marketplaces did.
3. Integrations waiting on paperwork. Payment gateway approval, WhatsApp Business verification, bank APIs: these run on other people's clocks. We start every one in week one, because the approval that takes three weeks costs nothing if it runs alongside the build and costs three weeks if it starts after.
4. Payments, refunds included. Taking money is a day. Handling declines, retries, refunds and the invoice your accountant needs is the real work, and pretending otherwise just moves the time after launch, where it is more expensive.
The team that hits these numbers
Timelines are a function of team shape more than team size, and the shape that hits 8 to 12 weeks reliably is small and senior: a designer, two engineers, and a lead who is hands-on, with QA joining from mid-build. Adding people to an MVP rarely compresses it, because the constraint is decisions and integration order, not typing speed; a six-person team on a ten-week MVP mostly produces meetings.
Two shapes to be wary of on a vendor's plan. A team with no designer at all, which converts every screen into an engineering improvisation you pay to redo; and a rotating cast, where the engineer who made week three's decisions is gone by week seven. Continuity is a schedule feature. When we quote an MVP, the people in discovery are the people in the build, which is one of the quieter reasons the estimates hold.
Two real timeline shapes from our own work make the table concrete. TurboType, a focused single-flow web product, went from idea to launch in weeks, at the fast edge of the table, because there was one platform, one flow, no payments and a founder-level decision maker in the room. BookMyPodcastStudio, a two-sided marketplace with listings, search and booking, sat at the far end, for every reason the marketplace row predicts: two user types, supply onboarding and payment flows. Same team, same process, a fourfold difference in calendar, and the difference was entirely in the scope column.
The question behind the question
"How long does an MVP take" usually means "how long until I know if this works". Those are different numbers, and the second one is the one to plan around.
Knowing takes the build plus six to eight weeks of real usage: enough time for actual users to hit the core flow, for the retention picture to mean something, and for you to run the experiment you built the MVP to run. So the honest planning horizon from kickoff to evidence is about four to five months. Founders who budget only to launch day routinely find themselves out of runway at the exact moment the product starts producing answers.
This is also the correct lens for every scope argument during the build: a feature that adds two weeks must make the learning better, not the demo. Most do not.
Can you not just build it with AI in a weekend?
Parts of it, yes, and we do: AI-assisted development is materially faster at generating screens, endpoints and test scaffolding, and it is one reason the 8-to-12-week band has held steady while MVPs have grown more ambitious. We rebuilt our own website in three days using AI heavily, and wrote up exactly what that did and did not prove.
What a weekend build does not include is the part that makes an MVP an experiment rather than a demo: payments that survive a declined card, accounts that survive a password reset, data you can trust, and a measurement plan. No-code tools sit in the same place: excellent for the 2-to-3-week validation row of the table, increasingly expensive to escape once real customers and real edge cases arrive.
Questions people ask
How much does it cost to build an MVP?
Timeline and cost move together, since a team-month is the unit of both. Between 3 and 8 lakh for a working product with one real feature, and 5 to 25 lakh for a sellable first version; the four rungs, the worked estimate and what moves each number are in our MVP development cost guide. The 8-to-12-week MVP in this article is the third rung there.
How do you develop an MVP without wasting the budget?
Cut to one platform, one user type and one core flow, launch the second half of your feature list only after real users vote, and spend the first fortnight on decisions rather than code. The full process is on our MVP development page.
What comes after the MVP?
Six to eight weeks of measured usage, then one of three honest outcomes: double down, adjust the core assumption, or stop cheaply. Teams that define the success number before launch, as covered in our AI readiness self-test for AI products, find this decision far less painful.
Can an MVP take four weeks?
Yes, if it is genuinely one flow with no payments, or a landing page with manual fulfilment behind it. That is not a lesser option; testing demand before building supply is often the smartest first experiment available.
The honest summary
Eight to twelve weeks is real, but only for a genuinely minimum product, with decisions made daily and integrations started on day one. The fastest MVPs we have shipped were not the ones with the biggest teams; they were the ones where the founder cut scope without sentiment and answered questions the same afternoon. The build is our job. The pace, more than anyone admits, is yours.