You have a launch window, a board expectation, or a customer commitment, and every vendor quotes a different timeline with no explanation of what drives it.
Most production-grade MVPs take 10 to 16 weeks from kickoff to production. The variable is rarely engineering throughput — it is decision latency on the client side. Builds with one empowered decision-maker consistently finish faster than builds with a committee, often by weeks. A quote promising six weeks is usually pricing a prototype, and a build running past twenty weeks has normally had its scope moved after work started.
The schedule risk you control is the answer turnaround. A build that needs a decision every few days and waits a week for each one adds a month without anyone writing a delay into a plan. Before kickoff, name one person who can approve scope changes without convening anyone, and agree a turnaround — two business days is workable. If that person cannot be named, the honest estimate is longer than sixteen weeks regardless of who builds it, and it is better to know that at the start.
What actually slows an MVP down
- Decision latency dominates. Engineering time is broadly predictable. Waiting three days for an answer about how a workflow should behave, four times across a build, is two weeks nobody scheduled.
- Non-functional work is invisible in the estimate. Authentication, permissions, environments and deployment are real weeks. If they are missing from the timeline they are also missing from the product.
- Scope moves after work starts. Not through bad faith — through the fourth obviously-small addition, which happens to touch the data model.
How to protect the timeline
-
01
Name one person who can decide, and tell the build team that is who they ask. Committees are the single largest source of timeline slip we see.
-
02
Write the definition of done before kickoff. Not the feature list — the observable condition that makes the build finished.
-
03
Ask any vendor which weeks are engineering and which are non-functional work. A timeline with no answer is a prototype timeline.
-
04
Block two hours a week in your own calendar for the build. Reviews that wait for a gap in your diary become the critical path.
-
05
Agree what gets cut if you slip. Deciding that under pressure, mid-build, is how quality goes rather than scope.
Holding the definition of done is harder than writing it. Six weeks in, a stakeholder asks for one more small thing and it genuinely is small — but it is the fourth one and it touches the data model. What protects a timeline is not a document, it is a person with the standing to say no to the founder, and that is usually what a first-time team does not have. It is why our Build engagements are milestone-gated rather than time-and-materials.
More on MVP timelines
A prototype can. A production-grade system with authentication, permissions, environments and real data handling generally cannot. Six-week quotes are usually honest about the work they include and quiet about the work they exclude.
Almost always scope movement after work started, or a decision bottleneck. Genuine engineering complexity shows up in the estimate; these two do not.
Rarely, and often the reverse on a small build — coordination overhead grows faster than output. If the constraint is decision latency, which it usually is, more developers make no difference at all.
More on Custom Application Development
Still not sure this is your problem?
A 20-minute fit check. We will tell you if it is something you can fix without us — that happens often enough that we lead with it.
Book a Strategy Session →Browse every answer.
The full Solution Desk — specific questions, straight answers, no gate.
Open the Solution Desk →