tech
MVP (Minimum Viable Product)
The smallest version of a product that delivers value and lets you learn from real users.
Definition
An MVP (Minimum Viable Product) is the simplest version of a product that lets you test the core value proposition with real users and learn from their response. Popularized by The Lean Startup. The principle: stop guessing what the market wants, ship something minimal, see what happens, iterate. Common misuse: 'MVP' as an excuse to ship broken product. The 'V' in MVP is Viable - it has to actually work and deliver value, just narrowly.
What makes an MVP truly viable
Three criteria distinguish a real MVP from a broken prototype. One, delivers genuine value to a defined user segment: a real user could pay money for it (and ideally has). Two, is reliable enough for repeated use: not pretty, not feature-complete, but does not crash or corrupt data. Three, generates clear learning signal: outcomes tell you something specific about market demand, pricing, or product fit. Common US startup mistakes that violate the V in MVP: shipping a landing page that promises a product not yet built (this is a smoke test, not an MVP), shipping a product that crashes regularly (this is a prototype, not an MVP), shipping a product so narrow it does not deliver value (this is a feature, not an MVP). The discipline: smallest scope that still meets all three criteria.
MVP strategies for US service businesses
Service businesses approach MVPs differently from software startups. Four practical paths. Manual MVP: deliver the service entirely by hand for early customers; learn the work intimately before automating. Most US successful service-to-software businesses (Basecamp, ConvertKit, Drift) started here. Concierge MVP: white-glove version with extensive customer hand-holding; trade margin for learning and iteration speed. Wizard of Oz MVP: software interface front-end with humans manually fulfilling the work behind the scenes; tests demand without full automation investment. Productized service MVP: defined scope, fixed price, repeatable delivery; not yet software but no longer pure custom. For US service businesses, the MVP question is rarely 'should we build software' but 'what scope and process should we standardize first'.
Measuring MVP success in the US market
MVP success is not revenue or user count; it is learning velocity and signal quality. Four metrics that matter. Conversion to paid: do prospects actually pay (not just sign up free)? Paying customers signal real demand. Retention curves: do paying customers stay? Three-month retention above 60 percent for B2B SaaS suggests fit; below 40 percent suggests serious mismatch. Activation rate: percentage of new users who complete the core workflow (typically called the 'aha moment'). Word-of-mouth signal: organic referrals, referral velocity, NPS scores. US benchmarks for MVP traction: 10 to 30 paying customers within 90 days for B2B SaaS, 50 to 500 paying customers for B2C, 3 to 5 referrals per active customer monthly. Below these levels suggests the value proposition needs refinement before scaling acquisition.
When to evolve beyond MVP
MVP is a phase, not a permanent state. Three signals indicate readiness to evolve. One, you can articulate the value proposition precisely from customer language - they tell you why they bought. Two, retention is durable - cohort analysis shows customers staying 6 plus months without intensive hand-holding. Three, acquisition cost is predictable - you can spend a defined dollar and expect a defined yield in qualified leads or signups. At that point, the work shifts from learning (MVP phase) to scaling (growth phase). The transition requires different team composition, investment patterns, and metrics. US founders often misjudge timing: scaling before MVP signal is clear wastes capital; staying in MVP mode past the signal misses growth windows.
FAQ
How small is too small for an MVP?
Too small when it cannot deliver enough value for someone to pay or repeatedly use it. The classic test: would a real user, today, choose your MVP over the next-best alternative for at least one specific use case? If yes, MVP is large enough. If no, you have not yet defined a viable product. US startup history is littered with smaller-than-needed MVPs that generated no signal because users did not engage long enough to evaluate. Err toward slightly larger scope at v1 to ensure signal quality.
Should I build my MVP myself or hire developers?
Depends on technical comfort and time. US founders with software engineering background often build MVPs themselves in 4 to 16 weeks at zero direct cash cost (high opportunity cost). Founders without engineering skills face a choice. Option one: learn enough no-code tools (Bubble, Webflow, Glide, Softr, Lovable, Replit Agent) to build a basic MVP yourself in 4 to 12 weeks. Increasingly viable as AI-assisted development matures. Option two: hire offshore developers (Toptal, Upwork senior tier) at 30 to 80 dollars per hour for 200 to 1500 hour MVP build, total 6K to 100K. Option three: hire US development agency at 20K to 250K for full MVP. Option four: technical co-founder; gives up equity but provides full alignment. The right choice depends on capital availability and learning goals.
How much should an MVP cost?
Wildly variable. No-code MVP built by founder: 100 to 5000 dollars (tool subscriptions, occasional consulting). Lean MVP built by founder and 1 to 2 contractors: 5K to 50K. Software MVP built by agency or in-house engineering team: 50K to 500K. Hardware or regulated industry MVP: 100K to 5M. The right budget is the amount that lets you ship and learn within your runway. US founders consistently overspend on MVPs; rules of thumb: spend less than 25 percent of available runway on MVP build, target 3 to 6 month timeline from idea to first paying customer, prioritize learning velocity over polish.
What if my MVP fails?
Most MVPs do, in the sense that the initial hypothesis is wrong. The successful path is usually: ship MVP, learn it does not work as expected, identify what users actually want, pivot the offering, ship MVP v2, repeat 2 to 5 times before signal emerges. Famous US startup pivots after MVP failure: Slack (started as gaming company Glitch), Instagram (started as check-in app Burbn), Twitter (started as podcast platform Odeo). MVPs that 'fail' usually generate valuable learning if you actually paid attention to signal. The real failure mode is shipping MVP without measuring what users do; that is wasted investment regardless of outcome.
Should I keep MVP scope small or add features quickly?
Resist feature additions until MVP signal is clear. The temptation when users complain about missing features is to add them; the discipline is to ask 'are users committed enough that this matters' before building. Most US MVP early users are not yet representative of the broader market; building features for the first 5 customers often produces a product that does not fit the next 50. Use the rule: do not add a feature until 3 plus customers independently request it AND you have a hypothesis about how it changes the underlying business model. Most feature requests can be politely deferred without losing the customer.
In your business
- →MVP must be Viable - actually deliver value, even narrowly
- →Define what you're learning before building - an MVP that doesn't answer a question is just a small product
- →Iterate based on user behavior, not user opinions - what they do beats what they say