How Long Does an MVP Actually Take, Start to First User

For: A founder or COO at an Indian SMB or early-stage startup who has just received a 4–6 week MVP promise from a dev partner and cannot tell whether the clock starts at signed contract or at something else entirely — and cannot afford to explain a three-month delay to their investors or first pilot customers

A realistic MVP goes from signed contract to first real user in 10 to 16 weeks for a straightforward SaaS product, and 20 to 32 weeks if it touches payments, lending, or health data. The 4-6 week number your dev partner quoted is almost always the build phase in isolation — it excludes discovery, environment access, integration sandboxes, UAT, and the two-week stall in week one when your team cannot produce a Razorpay merchant ID or a named subject-matter expert. The clock a founder cares about — contract to first paying pilot user — starts earlier and ends later than the clock a vendor quotes.

This post breaks that calendar down phase by phase, marks which weeks are on the vendor and which are on you, and names the three things that most reliably push an MVP past its promised date. It also lists what you can do in week zero — before the contract is even signed — to compress the whole thing.

Why the quoted timeline and the real timeline are different numbers

When a dev partner says "4-6 weeks," they usually mean: from the moment we have a locked scope, working credentials for every third-party service, a designated point of contact who can approve decisions within 24 hours, and a signed-off wireframe — from that moment, our engineers need four to six weeks. That is a defensible statement. It is also not the statement a founder hears.

The founder hears: from contract signature, first user in six weeks. The gap between those two readings is where projects die. The Standish Group's 2024 CHAOS Report found that 66% of software projects exceed their timeline or budget, and one in five gets cancelled outright. The top causes were unclear requirements (39%), scope creep (33%), inadequate planning (29%), and communication breakdowns (25%). Technology issues ranked last at 17%.

Notice what is missing from that list: engineering velocity. The problem is almost never how fast people can write code. It is how fast decisions get made and how fast access gets granted.

For context on the shape of a normal MVP calendar: Upsilon IT's 2026 guide reports a typical MVP takes 3-4 months from discovery to launch, with simple single-feature MVPs shipping in 4-6 weeks and fintech or regulated products needing 5-8 months. That matches what we see across Indian SaaS engagements. A 4-week MVP is real, but it describes a very narrow product category: one core workflow, no payments, no regulated data, one integration at most, and a founder who already knows exactly what to build.

The five phases of an MVP development timeline, and who owns each week

Here is the calendar broken into recognisable phases, with client-owned weeks marked. Treat this as the shape of the number, not a quote — your product will move the ranges up or down.

Add it up: 8 to 19 weeks for a standard SaaS MVP with no regulatory overhead. The vendor owns the 3-5 week middle. The client owns the two bookends — and the bookends are where most of the slippage lives.

Phase 0: pre-contract discovery (1-3 weeks, shared)

This is the phase founders skip and then pay for later. A locked scope with acceptance criteria takes one to three weeks of real work: two or three workshops, a wireframe pass, a decision on tech stack, and a list of every third-party service the product will touch. If you sign a contract before this is done, you are not shortening the timeline — you are moving discovery inside the build phase, where it becomes scope creep.

Phase 1: kickoff and access (1-4 weeks, mostly client)

This is the single most under-estimated phase in the entire MVP calendar. The vendor cannot start real work until they have: credentials to your existing systems (if any), a sandbox account for every integration, a named SME who can answer domain questions within 24 hours, and sample data or a data-generation plan.

The stall pattern is depressingly consistent. G2's 2024 onboarding data found 47% of businesses face difficulties in onboarding due to problems with accessing infrastructure. In construction, a related industry with hard start-date deadlines, 76% of contractors experienced delayed project start dates due to clearance-to-work and access issues, and 94% blamed process failures rather than the underlying compliance requirements. The parallel is exact. It is not the requirement that kills the timeline. It is the internal process for satisfying the requirement.

Phase 2: first usable slice (3-5 weeks, vendor)

This is the number your vendor was quoting. A single core workflow, end to end, deployed to a staging environment, ugly but functional. If phase 1 is clean, this phase runs on schedule roughly 80% of the time. If phase 1 dragged, phase 2 inherits every hour of that drag — because the engineers who were meant to build week 2 are now doing week 5 of phase 1's work.

Phase 3: integration and hardening (2-4 weeks, shared)

Payments go live, authentication moves off dev credentials, error states get built, basic load handling gets tested. If your MVP touches UPI, this is where Razorpay's production onboarding process — KYC verification, partner-program enrollment, and API key generation before a sandbox credential can be promoted to live — becomes the critical path. That process depends on the client supplying business documents upfront. If your GST registration or bank proof is not ready on day one of phase 3, this phase becomes a five-week phase.

Phase 4: UAT and rollout (1-3 weeks, mostly client)

The vendor is largely waiting. The client is testing, gathering feedback from internal users, and onboarding the first real customer. This phase compresses if you have a UAT script ready and a designated tester with cleared calendar. It expands to four or five weeks if UAT is being done by the CEO in the gaps between other meetings.

The three things that most often add weeks — and the early signal each one gives

1. A single named SME who is double-booked

Every MVP needs one person on the client side who understands the domain deeply enough to answer questions like "what happens if a partial refund is initiated after the invoice is already reconciled?" If that person is the founder, and the founder is also raising a round, the answer to that question arrives three days late and the build stalls waiting for it.

Early signal: in week one, ask your dev partner how many open questions are waiting on the client. If the number is above five and not shrinking, phase 2 is already at risk. The Standish Group found that teams with high decision latency — those slow to resolve blockers — achieve only an 18% project success rate, versus 63% for teams that decide quickly. Decision latency, not engineering skill, is the strongest predictor of on-time delivery.

2. Sandbox credentials for a regulated integration

UPI, lending APIs, health data, KYC providers, insurance rails — every one of these has an onboarding process that takes one to four weeks and depends on documents you have to gather. Razorpay sandbox keys are quick; production keys are not. A lending partner's UAT environment can take three weeks to provision. Nobody flags this in the SOW because everyone assumes the client already has the credentials.

Early signal: the phrase "we'll get those credentials sorted next week" in the kickoff call. That means they are not sorted, and nobody has started. Ask specifically: who on your team owns getting the Razorpay merchant account promoted to live, and what documents do they need today? For a sense of how this plays out on a real fintech build, our Cashpo lending MVP and GimBooks accounting SaaS both had integration onboarding on the critical path from day one.

3. Scope that keeps growing during the build

The Standish data puts scope creep at 33% of project failures. In MVP work, it looks like this: a stakeholder sees the staging build in week three, gets excited, and asks for "just one small addition." Multiply that by four stakeholders and you have added two weeks to a six-week build.

Early signal: the acceptance criteria document is either missing or vague. If your SOW says "user can manage invoices" instead of "user can create, edit, mark-paid, void, and export invoices as PDF; edit is disabled after status = paid" — you have a scope-creep problem waiting to happen.

An illustrative worked example

Illustrative only. A two-integration SaaS MVP — a B2B invoicing tool with Razorpay for payments and Google OAuth for login, no existing data to migrate, one client-side SME available half-time, standard web stack. Not a quote.

• Week 0 (pre-contract): 2 weeks of discovery, wireframes, locked acceptance criteria
• Weeks 1-2: Kickoff, environment setup, Razorpay sandbox live by day 4, Google OAuth credentials live by day 3, SME onboarded
• Weeks 3-6: Core build — invoice creation, listing, payment link generation, payment webhook, basic dashboard
• Weeks 7-9: Razorpay production keys, error handling, email notifications, staging deployment, security basics
• Weeks 10-11: Client UAT, bug fixes, first pilot user onboarded

Total: 11 weeks from contract to first user, 13 weeks from first discovery call. Change any assumption — a second integration, a client SME who is fully booked, a regulated data flow — and the calendar moves right by two to four weeks per change.

The cost of compressing the timeline

Founders sometimes ask if throwing more engineers at the problem cuts the calendar in half. It does not. Upsilon's guide notes that compressing an MVP timeline below three months usually raises costs by 20-40% because of the communication overhead. The reason is Brooks's law, still true forty years on: adding people to a late project makes it later. What actually compresses the calendar is removing decisions from the critical path, not adding engineers to it.

What to do in week zero to shorten the whole thing

These are the moves that pay back the most calendar time, in rough order of impact:

1. Name one decision-maker with a 24-hour SLA. Not a committee. One person who can approve scope questions same-day. If that is the founder, block two hours per day for the duration of the build.
2. Get every credential started before the contract is signed. Razorpay KYC, Google Cloud project, domain purchase, hosting account, GitHub org, whatever your stack needs. Most take days of elapsed time even when active work is minutes.
3. Write acceptance criteria at the sub-feature level. Not "user can pay" — "user can pay via UPI, card, or net banking; failed payments show error state X; successful payments trigger webhook Y and email Z."
4. Identify your first pilot user before week 4. The vendor cannot ship to a user who does not exist. If you are still hunting for pilot customers when the build is done, phase 4 becomes a phase 4-through-8.
5. Pre-schedule UAT. Block calendars now for the testing week that is 10 weeks away. It will not happen otherwise.
6. Kill nice-to-haves before they enter the SOW. Every feature that is in the MVP but not on the critical user journey is a feature that will steal a week from something that matters.

What would turn this range into a real quote

A defensible timeline for your specific MVP depends on three things a vendor needs to know before quoting:

• How many integrations, and which ones. Two standard ones (Google OAuth, Razorpay) is very different from four including a lending partner and a KYC provider.
• Whether the product touches regulated data. Health, financial, or lending data adds compliance work that can double phase 3.
• How much of the discovery work is already done. Locked wireframes and written acceptance criteria can cut two to four weeks off the front of the calendar.

If you have a 4-6 week promise on the table and want a second read on whether the calendar holds up, that is a scoping conversation, not a blog post. Our offerings page and the India studio is where those conversations start, and past builds like Vahak's logistics marketplace and HealthPotli's e-pharmacy show how the phase structure plays out under real regulatory and integration pressure.

Frequently Asked Questions

Is a 4-week MVP timeline ever realistic?

Yes, but only for a narrow product profile: one core workflow, no payment integration, no regulated data, wireframes already locked, and a founder available for same-day decisions. Anything with UPI, lending, or health data will not fit in four weeks because the third-party onboarding alone consumes most of that window.

What does an MVP actually cost in India?

The cost model has three main drivers: number of integrations, whether the product handles regulated data, and how much of the discovery is already done before the build starts. A simple two-integration SaaS MVP sits in one range; a fintech or health MVP with production compliance sits in a range two to three times higher. To turn any range into a real number you need a locked scope, a list of every third-party service, and clarity on whether existing systems need to be integrated with. That is a scoping conversation, not a rate-card question.

Who is responsible when the MVP is late — the vendor or the client?

Most of the time, both, but not equally. The Standish Group data shows unclear requirements, scope creep, and inadequate planning cause more than 60% of overruns — all of which are shared responsibilities that skew toward the client. Engineering capacity is rarely the bottleneck. If your MVP is running late, the first place to look is the queue of open questions and pending approvals, not the engineering team.

Does hiring a bigger team make the MVP ship faster?

Usually not. Adding engineers past a small core team increases coordination overhead more than it increases throughput, and compressing a three-month MVP into two months typically raises cost by 20-40% for the same output. The calendar responds much better to removing decisions from the critical path — pre-cleared credentials, locked acceptance criteria, a single fast decision-maker — than to adding developer headcount.

Should we sign the MVP contract before or after discovery?

Discovery should happen either before contract signature or in a small paid discovery engagement that precedes the build contract. Signing a fixed-scope, fixed-timeline MVP contract without locked wireframes and written acceptance criteria is the fastest way to guarantee scope disputes in week four. If a vendor is willing to quote a firm 4-6 week timeline without seeing a wireframe, treat that as a signal to slow down, not speed up.