Most MVPs that reach real users take eight to fourteen weeks. The ones that run to six months rarely failed in engineering — they failed in scoping, in a decision nobody would make, or in a third-party integration nobody budgeted time for. If you want a date you can hold a team to, the honest answer depends on the shape of the product, not the length of the feature list.
We publish what an MVP costs in India separately. This is the other half of the question, and the one founders get burned on more often, because a quote that slips by two months costs you a funding window.
First, the thing that actually sets the timeline
It is not how many screens you have. It is how many unknowns you have.
Twelve screens of CRUD against your own database is predictable work. One screen that has to reconcile against a bank’s sandbox, or wait on a KYC vendor’s response codes, or match an exchange’s file format, is not. The first is estimable to within a few days. The second is estimable to within a few weeks, and anyone who tells you otherwise has not done it.
So when you read the ranges below, count your external dependencies first. Each live integration with a party you do not control is the single biggest variance in the plan.
Realistic ranges by product shape
These are the bands we see with a small senior team — typically two to three engineers plus design, working to a decision-maker who is actually available. Not research figures; what the work takes.
- Single-flow MVP — 4 to 6 weeks. One job done well. A booking flow, an intake-and-review tool, an internal dashboard replacing a spreadsheet. Auth, one core flow, basic admin. No payments.
- SaaS MVP with auth, billing, roles and an admin panel — 8 to 12 weeks. The moment you have subscriptions you have a billing state machine, dunning, plan changes and an invoice nobody wants to hand-write. Multi-tenancy decisions made here are expensive to reverse, so this is where senior time earns its keep.
- Two-sided marketplace — 10 to 16 weeks. You are building two products and the matching between them. Supply onboarding is usually the half that gets underestimated.
- Anything regulated — add 4 to 8 weeks, and it is not code. Fintech, health, lending, investing. The build is ordinary; the sandbox access, the entity paperwork, the audit trail and the sign-offs are the path. Start that paperwork in week one, in parallel, or it becomes the critical path in week nine.
- An AI feature inside the MVP — the model is days, the evaluation is weeks. Wiring a model in is a sprint. Knowing whether it answers correctly, and not confidently wrongly, needs a labelled set and a harness. Teams that skip this ship a demo, not a product. We have written about why that bites.
What a ten-week build actually looks like
Shape, not gospel. But if your plan looks nothing like this, ask why.
- Week 0 — before anyone writes code. Agree the one outcome the MVP has to prove. Name the single decision-maker. Open every third-party account that needs a human to approve it.
- Weeks 1–2. Core data model, auth, deployment pipeline and a staging environment with realistic seed data. Unglamorous, and it is what stops week eight being a mess.
- Weeks 3–6. The main flow, end to end, including the ugly states — empty, failed, partially complete, retried. Demo something working at the end of every week.
- Weeks 7–8. Integrations and the admin surface your own team will live in. Expect the first real surprises here.
- Week 9. Hardening. Error handling, logs you can actually read, basic analytics, the security pass.
- Week 10. Pilot with real users. Not a launch — a pilot.
Notice what is in weeks one and two. Founders often push to “start on the features” and treat the pipeline and staging as overhead. That trade buys you a fortnight and costs you a month, because without a staging environment holding realistic data, every bug after week six becomes an argument about whether it is real. Our view on the infrastructure side is simply that an MVP deserves the boring version of it, done early and cheaply.
The five things that actually cause slippage
- Scope creep wearing a feedback costume. “Small addition” is how an eight-week build becomes fourteen. The fix is not saying no to everything — it is a visible list where every addition pushes something else out, and the founder picks.
- No single decision-maker. Three co-founders with equal votes and different instincts will stall a build harder than any technical problem. Days disappear into waiting.
- Third-party onboarding. Payment gateway approvals, KYC vendors, bank and exchange sandboxes, app-store review. These run on someone else’s calendar. Every one of them should be started in week zero, and the fact that it has not been is the most common reason a plan is already two weeks behind before any code is reviewed.
- Design arriving late, or arriving as pictures. A beautiful static mockup with no empty states, no error states and no loading behaviour is about sixty per cent of a design. Engineering invents the rest, then redoes it.
- Treating the MVP as version one of the whole product. This is the expensive one, because it is a strategy error that looks like a scope error. An MVP exists to settle one question. If it is carrying your three-year roadmap, you are not building an MVP, and you should price and plan it as custom software instead.
What to cut, every time
Cut the settings page. Cut role granularity beyond admin and user. Cut the native app if the web will answer the question. Cut the dashboard of charts nobody has asked a question of yet. Cut onboarding tours. Cut the second payment method. Cut internationalisation. Cut the design system; you need components, not a system, until you know the product survives.
Keep anything that would be dishonest to fake in front of a real user, and anything that is genuinely expensive to retrofit — your data model, your tenancy boundary, and an audit trail if you are anywhere near money or health.
Does building in India compress the timeline?
It changes the cost, not the calendar. Ten weeks of work is ten weeks of work. What does change the calendar is seniority and overlap: a small senior team in your timezone, or close to it, with a founder who answers within the day, will beat a larger cheaper team working across a twelve-hour gap — every time, and by more than people expect. Throwing bodies at a late MVP is the oldest way to make it later.
When not to build one at all
If the question you are trying to answer is “will people pay for this”, there are cheaper instruments than a build — a landing page, a concierge version run manually, a spreadsheet and a WhatsApp group. We have argued the same thing in a different context, about building versus buying: the cheapest code is the code you did not need. Build when the unknown is genuinely in the product, not in the market.
If you want a second opinion on a plan you have already been quoted, we are happy to read it. How we work with founders is here.
Frequently asked questions
How long does it take to build an MVP?
Most MVPs that reach real users take eight to fourteen weeks with a small senior team. A single-flow product with no payments can land in four to six. A two-sided marketplace is usually ten to sixteen. Add four to eight weeks for anything regulated, and spend it on sandbox access and paperwork rather than code.
Can an MVP be built in four weeks?
Yes, if it has one flow, no payments, no external integrations and a decision-maker who answers the same day. The constraint is scope, not speed. What cannot be done in four weeks is a four-week scope plus billing, roles, an admin panel and a KYC vendor.
Why do MVP projects slip?
In our experience, five causes account for most of it: scope added as feedback, no single decision-maker, third-party onboarding that runs on someone else’s calendar, design delivered without empty and error states, and treating the MVP as version one of the full product. Only the third is outside your control, and even that one is usually a planning failure rather than bad luck.
Should the MVP include an AI feature?
Only if the question the MVP exists to answer depends on it. Wiring a model in takes days; knowing whether it is reliably right takes weeks of evaluation work. If the AI is a differentiator you must prove, budget for the harness. If it is a nice-to-have, ship without it and add it when you have real usage data to evaluate against.
Does a bigger team make an MVP faster?
Past three or four engineers, rarely. Coordination cost rises, the data model gets contested, and review becomes the bottleneck. Seniority and founder availability move the date far more than headcount does, and adding people to a late project reliably makes it later.