When does an MVP make sense vs a full build
Build an MVP (minimum viable product) when the core business hypothesis is unvalidated and the cost of learning is the load-bearing budget concern. Build a full product when the business hypothesis is validated and the goal is production-grade software that survives 3 to 5 years. Most engagements that start as "let's do an MVP" should actually be a written specification and a focused production build — the MVP label often hides a desire to skip the specification work, which is exactly when projects go wrong.
The longer answer
The MVP vs full-build decision is one of the most commonly misunderstood early choices in software engagements. The MVP concept — ship the smallest thing that proves the business hypothesis, learn, iterate — is genuinely useful when the hypothesis is unvalidated. The label gets misapplied to engagements where the real problem is something else.
When MVP is the right answer
Three scenarios. Unvalidated business hypothesis. You think customers will pay for X but no one has actually paid you for X yet. Ship the smallest credible version of X, get real customers paying for it, learn what they actually want, then build the production version. New-market entry. Your business is moving into a market where you do not yet know what features matter. MVP lets you discover the answer faster than market research can. Internal proof-of-concept. A senior team needs to evaluate whether a software approach is feasible before committing to a multi-month engagement.
An MVP in these scenarios is genuinely small — 4-12 weeks of engineering, deliberately under-featured, instrumented for learning rather than for revenue. Pricing: $20k-$80k.
When MVP is the wrong answer
Three common misuses. Validated hypothesis, false economy. You already have customers paying for the workflow; "let's do an MVP" is hiding a desire to underbudget the real build, which produces software that does not survive year-one production load. Just build the real thing. MVP as specification avoidance. The buyer wants to skip the written specification work and "see something" before committing. The honest fix is to scope the specification as a paid deliverable and have the conversation; the MVP label here is hiding the wrong problem. MVP as scope dodge. Stakeholders disagree on what should be in the product, and "let's MVP it" is a way to dodge the disagreement. The honest fix is resolving the stakeholder disagreement, not shipping software that papers over it.
The honest MVP shape
A good MVP has three properties. First, it is genuinely small — under 12 weeks of engineering, ideally under 8. Second, it is honestly under-featured and labeled as such to the customers using it. Third, it is instrumented — you can see what users do with it, where they get stuck, what they want next. Software without all three is not an MVP; it is just a small build.
The full-build shape
Production software designed to survive 3-5 years: written specification, comprehensive testing, multi-role authentication, audit logging, observability, deployment pipeline, written runbook at launch. Cost: $75k-$500k+ depending on scope. Timeline: 4-12 months. The right answer when the business hypothesis is validated and the software is part of the business going forward.
Common follow-up questions
Can an MVP become a full product?
Sometimes yes, often no. Code written for "ship in 8 weeks and learn" is not usually code that survives year-3 production load. Plan for a refactor or rewrite between MVP and full-build if the MVP succeeds — budget that work explicitly rather than discovering it as scope creep.
How do I know if I need MVP or full build?
Ask: do customers already pay you for this workflow? If yes, you do not need MVP — you need a real build. If no, MVP is the right answer to learn whether they will pay before you build the production version.
What is the cheapest legitimate MVP?
$15,000-$25,000 for 4-6 weeks of focused engineering on a deliberately-narrow scope. Below that, you are building a prototype or no-code configuration, not an MVP — the distinction matters because the deliverable shape is different.
If this answer is useful and you have a real engagement in mind, the contact form routes directly to the principal — James Henderson is the single engineer who scopes, writes, and supports every engagement end-to-end.