The MVP shipped and still did not answer the question.
Users created accounts. The dashboard loaded. The team celebrated registrations. But the real assumption was whether a buyer would complete the workflow and pay. That step had been deferred to phase two.
An MVP is useful when the scope protects the test, not when it protects the feature list.
MVP proof
- 14 weeks
- GrowViral delivery
- Referral and viral marketing SaaS
- 12+
- third-party integrations
- Documented platform scope
- 2.5x
- higher campaign conversion
- Client-reported outcome
The GrowViral case study documents the product and reported result. It does not prove that every MVP should carry 12 integrations or can produce the same conversion change.
Start with an MVP when the next risk is user behaviour, not presentation.
Use a prototype when you still need to test comprehension or flow. Move to a fuller product when demand and operating needs are already known.
A fit01A named user has a painful job and the team can state the assumption that may still be wrong.
02The test needs working software, real data, or a real transaction to be credible.
03The buyer has budget for production ownership, measurement, and post-launch decisions.
Not a fit01The idea still needs cheap interviews or a clickable prototype before software.
02The scope is a complete roadmap disguised as a first release.
03Nobody owns recruitment, operations, or the decision that follows the test.
Prototype vs MVP
| Prototype | MVP |
|---|
| Question | Do people understand or want this concept? | Will real users complete the core job under real conditions? |
| Software | Simulation or limited technical proof | Production path with real identity, data, and measurement |
| Users | Interview or usability participants | Controlled real users or customers |
| Outcome | Design and proposition learning | Evidence for investment, product, or market decisions |
Scope
What the MVP engagement covers
01Assumption and success signal
Turn the brief into one decision, one risky assumption, and the observable signal that will support the next move.
02Prototype and code audit
Assess the existing flow, repository, data, dependencies, and ownership so validated work is kept and production risks are priced honestly.
03One complete product journey
Develop the smallest web, mobile, SaaS, or AI path that a real user can finish without manual theatre hiding the result.
Include the identity, permissions, reliability, security, support, analytics, and operations required for the test, without pretending the MVP is the finished company.
05Evidence and next-release decision
Instrument the path, review behaviour and failures, and separate a product signal from a technical issue before adding scope.
How it works
From assumption to production evidence
- Phase 1
01Name the decision
Define the user, problem, risky assumption, success signal, and decision the MVP must support.
- Phase 2
02Cut to one complete journey
Keep the minimum workflow, data, integrations, and controls needed for a real user to reach the outcome.
- Phase 3
03Release and observe
Put working software in front of controlled users and separate product failures from technical defects.
- Phase 4
04Decide what the evidence earns
Improve, expand, reposition, pause, or stop based on observed use rather than the original feature list.
Risk
MVP mistakes that corrupt the test
- Success means the app launched
- Launch is an event. Define the user or business behaviour that will make the release useful.
- Manual work is hidden
- Concierge operations can be deliberate, but record them. Otherwise the team cannot see what scale will cost.
- AI output has no evaluation
- Define test cases, failure classes, review, and fallback before treating an AI feature as production evidence.
- Every stakeholder gets one feature
- Consensus scope tests nothing well. The decision and user journey outrank internal symmetry.
Europe should narrow the test, not inflate the roadmap. Name the first country,
audience, working language, core journey, data roles, accessibility needs,
payment dependencies, support owner, and evidence threshold. Launch in several
countries only when cross-market behaviour is the assumption being tested.
Translation alone does not settle formats, content ownership, consumer terms,
tax, payments, or support.
The City Break Apartments
case
shows a product released to real users in Dublin with a defined booking and
keyless-entry workflow. It is adjacent European launch evidence, not an outcome
guarantee for a new MVP. The new release still needs its own cohort, baseline,
observation period, and stop or invest decision.
Scope and price
A focused MVP starts at $15,000.
Start with one assumption, one complete journey, production essentials, and the measurement needed for the next decision.
A broader product is priced after the MVP evidence shows which workflows and technical investments have earned the next phase.
Starting investment
Starts at $15,000
Focused MVPs usually take 6 to 14 weeks. Platforms, integrations, data, AI evaluation, and regulated controls can extend the plan.
Milestone control
Each phase has written scope and acceptance. New work enters only after it is priced and approved.
Post-launch support
Eight weeks of support are included for defects within the agreed scope while the team reads the first production evidence.