What is a Minimum Viable Product? Starting Small

Before anyone funds the full build, product teams put a minimum viable product (MVP) in front of real users. It has just enough features for early customers to use it and give feedback, and it exists to test a specific hypothesis.

Frank Robinson coined the term in 2001. Eric Ries popularized it a decade later in The Lean Startup (2011). They didn’t define it the same way, though. Robinson built his version around return on risk and Ries built his around validated learning, so a team’s scope cuts depend on which one it follows.

What Is a Minimum Viable Product?

Learning is the whole reason it exists. Nobody is trying to ship a smaller copy of the finished product.

The word “viable” sets the quality bar. If a release fails at its basic job, every comment ends up being about the breakage, and the team learns nothing about the idea.

What goes in depends on who the early adopters are (the people who feel the problem hardest) and on the one pain the product removes. Add the reason that user would pick this over their current workaround. Then comes the feature set, which should be the fewest features that let the user finish a single task from start to end.

Henrik Kniberg’s skateboard-to-car drawing (Crisp blog, 2016) is the easiest way to see where the line sits. Nobody can do anything with a front tire. A skateboard at least gets you from A to B, badly but really.

An MVP isn’t a rough draft of the final product, and it isn’t one finished piece of a larger build. A prototype that testers see but nobody ever releases doesn’t qualify either.

Ries puts it bluntly. The MVP is “not about creating minimal products,” and if all you want is a quick flip or you’re scratching a simple itch, he says you don’t need one.

Frank Robinson and Eric Ries Define the Term Differently

Robinson coined the phrase in 2001 and Ries brought it to a wide audience in 2011, but their goals weren’t the same. Robinson aims at return on risk. Ries aims at validated learning.

Robinson’s “MVP: How it Works” page (2008) on SyncDev defines the MVP as the product that “maximizes return on risk” for vendor and customer. Too few features and the product fails at launch. Too many cut the return and add risk. He starts scoping with a minimum viable market, then narrows down to the product.

Ries judges an MVP by one yardstick, which is validated customer learning per unit of effort. Any feature, process or effort that doesn’t feed the learning goal gets cut.

Steve Blank sits somewhere between the two. In The Four Steps to the Epiphany (2005), his customer development method called the same idea a “minimum feature set.” He had also advised IMVU, the company Ries co-founded, from around 2004.

A lot of guides credit Ries with coining the term. He didn’t. He popularized one that already existed.

In practice the split changes what gets cut. A feature survives Robinson’s test if it raises return faster than it raises risk, but under Ries’s it has to feed the learning goal or it goes.

Kniberg goes further and drops the term altogether. His 2016 post swaps “minimum” for “earliest” and splits “viable” into testable, usable and lovable, because “your ‘viable’ is my ‘horrible.'”

I’d use Ries’s learning test for day-to-day scope calls, since it’s easier to apply. Robinson’s framing earns its place when the question is how much to spend.

Hypotheses an MVP Tests and the Learning It Produces

An MVP bets that the problem exists and that this solution fits it. It also bets that customers will pay. Testing those claims produces validated learning, meaning evidence drawn from real customer behavior instead of opinion.

Startup post-mortems make the case for testing demand early. CB Insights (March 2026) analyzed 431 VC-backed startups that shut down since 2023, and poor product-market fit was behind 43% of the 385 where a reason could be identified.

An earlier CB Insights review of 101 post-mortems landed on no market need at 42%. The cohorts and labels differ, but the share is close.

CB Insights treats running out of capital as the last event in most startups that failed, not the root cause. Demand sits upstream of cash, so the testing order starts with the problem. Fit comes next, and price last.

The problem hypothesis asks whether the target user feels the pain often enough to act. Customer interviews can answer that, or a landing page that makes one promise.

The solution hypothesis is about whether this product, and not some other workaround, resolves the pain. Watching real usage of the core feature is the test.

Payment is the last one. The user hands over money or a firm commitment, which you can check with a pricing-page click, a paid plan, or a pre-order.

For the cheapest possible demand check, Ries points to the AdWords smoke test. A small ad campaign sends traffic to a signup page, and AdWords is Google’s ad platform, now called Google Ads.

The Build-Measure-Learn loop turns those tests into a routine. Ship the smallest test, record what customers do, then decide. Kniberg frames the working question as the cheapest, fastest way to start learning.

The loop repeats the way an iterative development cycle does. Each pass ends with a decision to persevere and build further, pivot to a changed approach, or stop.

Types of Minimum Viable Product With Examples

Teams usually pick from landing page, explainer video, concierge, Wizard of Oz, piecemeal and single-feature MVPs. Each one fakes something different and tests something different. Rework’s guide treats the names as working labels, not a standard.

Plenty of startups that went on to succeed started with one of these, and each test was sized to a single assumption.

Dropbox is the clearest video case, though the details get tangled. Drew Houston posted a screencast of an early prototype to Hacker News in April 2007 as part of his Y Combinator application. The famous numbers come from a second video, posted to Digg in March 2008. Houston has said the beta waiting list jumped from 5,000 to 75,000 overnight once that video reached Digg.

Many retellings merge the two videos or date the Digg jump to 2007. Hacker News comments dated 4 and 5 April 2007 already discuss the first screencast, and the waiting-list jump followed the March 2008 video.

Zappos was taking about $2,000 worth of orders per week within several months, and it made no profit, since Swinmurn bought each pair at retail before shipping it (The Lean Entrepreneur). Nielsen Norman Group (2024) cites it as a famous Wizard of Oz MVP. The website looked real, but the founder did the fulfilling by hand.

Buffer is the pricing example. Roughly two and a half months after its 30 November 2010 launch, about 4% of its users were upgrading to paid plans, with a little over 500 users at the time (Gascoigne, Buffer blog, February 2011). Before writing the product, Gascoigne had placed a pricing page between the landing page and the signup form to see which plan visitors clicked.

Andrew Mason has described Groupon’s first version as a WordPress blog reskinned with the new name, plus a script that emailed PDF coupons to buyers. Speckyboy’s roundup tags that setup as both a manual-first Wizard of Oz MVP and a piecemeal MVP, which shows how much the type boundaries overlap.

Which Type Fits Which Riskiest Assumption

Match the type to the assumption that would sink the product if it were wrong.

If demand is unproven, a landing page or explainer video is the cheap way to find out. Unproven delivery points to a concierge or Wizard of Oz test. Piecemeal suits the case where custom engineering is the open question, since you assemble the thing from existing tools. And when nobody knows whether people will actually use it, release a single feature to real users.

A landing page cannot show whether the product works, and a concierge test cannot show what automation costs. The type has to answer the open question, not just cost the least.

Minimum Viable Product vs Prototype vs Proof of Concept

Kanerika, StoriesOnBoard and Koombea all separate these by the risk each one reduces. Feasibility is the proof of concept’s job, usability belongs to the prototype, and demand is what the MVP tests.

A prototype is a working simulation of the product, built through software prototyping and shown to testers rather than customers. Usability.gov describes the range as paper drawings at the low end and a fully functioning site at the high end.

Most teams build the clickable version in one of the standard prototyping tools, Figma and ProtoPie among them (Nielsen Norman Group, 2024).

Functionality is where guides disagree. Cleveroad says a prototype holds no real logic or server connections, while Usability.gov describes high-fidelity prototypes that run as a full site. The working test is audience and purpose, since testers and stakeholders get prototypes and paying customers get an MVP.

A proof of concept is a narrow internal experiment on one risky function. Spotify’s early client shows how the lines blur. It began as a test of whether music could start the instant someone pressed play, measured in milliseconds, then went to friends and family as the team’s first testable release (Kniberg, 2016).

The MVP, by contrast, is live software used by real customers, with a deliberately limited feature set (UXPin, 2026).

When feasibility, usability and demand are all open, StoriesOnBoard sequences them from cheapest to most expensive, so proof of concept first, prototype second and MVP last. Skip any stage whose question is already answered.

The usual failure is a prototype treated as production code. StoriesOnBoard recommends marking prototype screens as design drafts and holding a formal handoff so engineering specs replace the placeholders.

How to Build a Minimum Viable Product

Each step narrows what the next one has to prove, so the order matters.

1. Name the target user and the problem, then record both on a Lean Canvas
2. List the assumptions that would sink the product if wrong, ranked by damage
3. Frame the job the user hires the product to do
4. Cut the feature list down to the minimum feature set
5. Choose the MVP type that fits the top-ranked assumption
6. Build in short, fixed-length iterations
7. Release to a small group of early adopters, not the public
8. Measure against targets set before launch, then decide the next move

Ash Maurya’s Lean Canvas (2010) is a one-page adaptation of Alexander Osterwalder’s Business Model Canvas, with nine boxes. Maurya suggests starting with the problem box. Customer segments come next, and the unique value proposition after that.

The job framing comes from Clayton Christensen’s jobs-to-be-done theory (Competing Against Luck, 2016), where customers hire a product for a job and fire it when it does that job badly. So the useful MVP question is which product the user would fire to hire yours.

Teams running Scrum get a cap built in, since the Scrum Guide (2020) fixes a Sprint at one month or less.

Getting the release to early adopters is manual work. Paul Graham’s essay “Do Things that Don’t Scale” (2013) calls recruiting users by hand the most common unscalable task, and Airbnb’s founders went door to door in New York to recruit users and help them improve their listings.

How to Choose the Minimum Feature Set

Most teams reach for MoSCoW, RICE or Kano. They don’t answer the same question.

MoSCoW traces back to DSDM, developed in the mid-1990s by what is now the Agile Business Consortium, and its Must Haves mark the minimum for an acceptable product. RICE is newer. Sean McBride at Intercom came up with it (January 2018), using conversion rate as the single goal when scoring ideas for his own team.

Noriaki Kano’s model (1980s) gives “viable” a precise meaning. Basic attributes are the price of entry, and customers stay neutral even when execution improves. Delighters earn extra satisfaction and cause no dissatisfaction when missing (Institute for Manufacturing, University of Cambridge).

Frameworks order the list but do not draw the line. The hypothesis under test does that, and a feature stays only if the test can’t run without it.

Tools for Building the First Version

A no-code builder suits a workflow hypothesis. Bubble, for one, lets you build, launch and run apps without writing code. Custom code is justified when the hypothesis depends on something a builder can’t do.

Lock-in is the documented limit. Bubble’s own guide says user data exports as CSV and through its API, and it lists logic and hosting lock-in beside data lock-in.

WeWeb, a competing builder, and LowCode Agency both report that Bubble applications do not export as source code. LowCode Agency still advises staying on the platform until a documented limit blocks the business, which beats a speculative rewrite.

For custom code, choose a tech stack the team already knows. Unfamiliar tools slow the first loop.

Which Metrics Show an MVP Worked?

Pick one metric per hypothesis and fix the target before launch. A target set after the data arrives always fits the data. Activation, retention, conversion and Net Promoter Score cover most MVP readouts.

Activation is the share of new users who reach the core value, such as finishing the first task. Mixpanel (2026) says acquisition without activation no longer counts.

Retention tracks how many users return after a set interval, and Mixpanel’s documentation calls it critical to product-market fit and long-term growth. Conversion, the share who pay or commit, gets measured against the payment hypothesis.

Net Promoter Score comes from Bain & Company (2003) and rests on one 0-to-10 recommend question. Scores of 9 to 10 are promoters, 0 to 6 are detractors, and the score is promoters minus detractors.

Thresholds are where sources disagree. Mixpanel’s 2024 benchmarks report put average week-one retention across industries at 28% for 2023, down from 50% in 2022.

Its 2026 B2B report records one-week retention of 5.0% in North America, the lowest of the regions it compares. Same publisher, different cohorts and measures, so the target has to come from a comparable category and not from a headline number.

Small cohorts are the usual failure mode. Mixpanel’s retention report weights its average by the users entering each cohort, so a handful of users cannot swing the line.

Compare each metric with its target. Hit it and you build further. If you miss overall but one segment sits far above target, pivot toward that segment. A miss everywhere means stop.

On product-market fit, Marc Andreessen defined it as a good market paired with a product that satisfies it, and said you can tell when customers buy as fast as you can make the product.

Holloway’s venture guide credits Andy Rachleff with coining the term and calls the Andreessen attribution a common mistake. It also frames fit as a continuum of traction, which is why a passing MVP does not prove it. The MVP validates its hypotheses, whereas fit means the market is pulling.

How Much Does a Minimum Viable Product Cost, and How Long Does It Take?

Published MVP cost ranges disagree widely because agencies draw the scope line in different places. Treat any single figure as a statement about that agency’s definition of an MVP.

• Clutch (2026) puts the average app development project at about $90,780 and roughly 11 months, across all app projects reviewed.
• UX Continuum (2026) says most MVPs cost $10,000 to $60,000, and a basic SaaS MVP runs $15,000 to $25,000 over 6 to 8 weeks.
• Keyhole Software (2026) quotes $40,000 to $120,000 over 2 to 4 months for a simple or MVP-tier project.

Clutch’s numbers on mobile app development cost describe whole app projects, so they are an upper reference and not an MVP quote.

The agency ranges meet on timeline at about two months but do not overlap on price. Keyhole’s tier assumes one platform, limited integrations and a simple interface, while UX Continuum sorts MVPs by feature complexity.

Keyhole names team composition, technology stack and change management as the variables that shift a budget.

App MVPs sit inside the wider mobile app development timeline, and Clutch’s 11-month average describes the full build, not the first test.

Budgets fail in two directions. phoenixNAP warns that over-allocating resources cancels the savings an MVP exists to deliver, while under-allocating produces a product that is not viable.

When a Minimum Viable Product Does Not Fit

An MVP fits badly when a bad release can’t be patched or withdrawn. Regulated medical device software and safety-critical systems fall in that group, along with hardware that needs expensive tooling. The learning still happens there, but it moves to concept models, prototypes and staged releases.

Products Where the Approach Breaks Down

Medical Design Briefs describes FDA design controls as starting once an initial concept exists and design inputs are formally documented. Early exploratory research, concept models and feasibility testing sit outside them, and the controls apply only to certain classes of device.

That description was written under 21 CFR 820.30, which has been marked “[Reserved]” since FDA’s Quality Management System Regulation (QMSR) took effect on 2 February 2026. Design and development requirements now come from ISO 13485:2016 clause 7.3, incorporated by reference into 21 CFR Part 820, so check how your device class is covered.

Software inside a device is covered separately. FDA’s General Principles of Software Validation guidance (final, January 2002) sets out the expectations for device software, and FDA’s Computer Software Assurance guidance of September 2025 superseded only its Section 6, which covers production and quality-system software.

In practice, early loops of the Build-Measure-Learn cycle can run on concept models and feasibility tests, but release to patients or clinicians cannot skip the design and development requirements.

Hardware raises a different barrier, which is tooling. GearBrain puts injection-mold tooling at anywhere from thousands of dollars for a simple enclosure to six figures for a complex mold, and changing a part after cutting means modifying or scrapping the tool.

Guides disagree on whether a hardware MVP must be a built unit. Mind the Product reports that many teams assume it must be, then argues for staging commitment through paper, prototype, soft tooling and hard tooling before production.

Common Mistakes That Undo the Learning

Scope creep hit 52% of projects completed in the 12 months before PMI’s 2018 Pulse of the Profession, up from 43% five years earlier. In an MVP it usually looks like the build growing past the test it was made for, until it can no longer ship in one iteration.

The opposite mistake is building too little. Userlytics names confusing the MVP with a minimum product as the most common pitfall, since it releases low-quality products that frustrate users.

Iterating without real users is another. LEGO Universe teams used Scrum and iterated heavily, but the releases stayed internal, and the finished game drew a lukewarm reception before it was shut down (Kniberg, 2016).

Shipping more features after a missed target skips the decision the loop exists to force.

Then there’s the full product that gets called an MVP. StoriesOnBoard reports teams folding months of scope into a release they still label an MVP, and suggests tying the launch to one success metric such as activation rate.

Kniberg also reports customers who hear “MVP” and expect a buggy, unfinished final delivery once the team moves on.

Code written to learn fast becomes technical debt if it ships as the foundation, and Bubble’s guide notes that debt builds up in no-code apps just as it does in code.

Minimum Viable Product FAQ

How does a minimum lovable product differ from an MVP?

Learning is the MVP’s job, and delight is the lovable version’s. Kniberg’s ladder puts the Earliest Lovable Product after the testable and usable stages, as the first release customers love, recommend and will pay for.

Does an MVP have to be software?

No. Concierge, Wizard of Oz, landing page and explainer video MVPs need little or no custom software, and Productboard notes that an MVP is not always a product.

Hardware teams stage paper models, prototypes and soft tooling before committing to a built unit.

How many users does an MVP need?

No fixed number applies. Kniberg’s guidance is that you need not test on all users, and that even a single user teaches more than none.

Interviews work with a handful of people, but a retention reading needs a larger cohort, because a few users swing the average too easily.

Can a large company build an MVP?

Yes. Kniberg describes a 60-person Swedish Police project that split a national system by region and crime type, then released version 1.0 to a handful of officers in one region.

Their early feedback shaped each later release before the nationwide rollout.

What Happens to a Minimum Viable Product After Validation

After validation the product gets extended, rebuilt or retired. Activation and retention data decides which, measured against the targets set before launch.

Check retirement first. If the core metric misses its target after repeated iterations, the build is done. Extending the code makes sense only when the stack scales and the architecture holds, and a product sitting on a no-code platform or a throwaway prototype gets rebuilt.

Extending buys speed, but every shortcut taken to launch stays in the codebase until someone pays it down. A rebuild gives you a clean base at the cost of the months a competitor spends shipping.

Position verified October 2026. The order changes if no-code platforms such as Bubble add source code export, since rebuilding would then stop being the only exit from platform lock-in.

• Author
• Recent Posts

Bogdan Sandu

Bogdan Sandu is a front-end developer at TMS Outsource with 8+ years of experience in web technologies. He writes about developer tools, software platforms, and web workflows based on daily hands-on use.

Latest posts by Bogdan Sandu (see all)

• Build or Buy an AI Chatbot for E-commerce: The Costs Nobody Budgets For - October 24, 2026
• How to Run a React App in VS Code Step by Step - October 23, 2026
• Transactional or marketing email: which messages your app should send itself - October 23, 2026