MVP (Minimum Viable Product)

What Is an MVP?

An MVP is the smallest working version of a product built specifically to test whether people want it. The cheapest way to test demand is putting a working product in front of paying customers. It's a purchase of information, priced in the features deliberately left out.

Eric Ries popularized the concept in The Lean Startup, framing it as the version of a new product that lets a team collect the most validated learning about customers with the least effort. The definition is often quoted and less often applied. The effort-minimizing half is easy to agree with, while the learning half requires stating in advance what result would change the plan.

Both words in the phrase are important, and teams often drop one. Minimum constrains scope to a single path through the product. Viable constrains quality: the thing has to work for a customer trying to do a job with it. A release that is minimal but not viable produces no information, because the failure it generates is about the build quality and says nothing about demand.

A common mistake is using it as a budget label. A first release gets called an MVP to explain why it is missing things, with no hypothesis attached and no criteria for what would count as a positive result. What separates an MVP from a small first version is that someone wrote down beforehand what they expected to observe and what they would do in each case.

MVPs also sit on a spectrum with lighter methods. A landing page test measures interest before building anything. A concierge approach delivers the outcome manually while the customer believes it is automated. A prototype tests a workflow without production code. Each buys different information at a different price, and the full MVP is the most expensive option on that list.

How Does an MVP Turn a Company's Budget Into Evidence?

An MVP turns spending into a measurable result. Wrong answers cost less the faster you find them. A team can ship in eight weeks and learn the market doesn't want the product. The same team can take a year to build and reach the same conclusion after losing far more time, and possibly the funding that would pay for a second attempt. An MVP is what keeps that cost small enough for the company to survive being wrong.

Specifications written before contact with customers encode assumptions as requirements. The workflow that seemed obvious in a planning document turns out to have a step nobody will do, and you only discover that after someone tries to use it. Shipping early turns assumptions into observations while you still have budget to act on them.

Committing to a minimum forces you to make a statement you can prove wrong. Deciding what to leave out requires knowing what the product is for, and deciding what would count as success requires naming a number before the result arrives.

How Is an MVP Built?

• The hypothesis and the decision come before any scoping. The team writes down what it believes, what evidence would support it, what would count as disconfirmation, and what the company would do in each case. Without the last part, a disappointing result produces a discussion about whether the marketing was adequate.

• One workflow is chosen and followed through. The product does a single job completely, from the entry point to the outcome the customer wanted. Ten features that each stop halfway teach nothing, because a customer who cannot finish anything cannot tell you whether finishing would have been valuable.

• Everything off that path is cut without ceremony. Administrative screens, configuration, bulk operations, secondary integrations, and most of the error handling for improbable states come out. Much of this work can be done manually when the customer base is small, which is often faster than building it and produces better information about what the automated version needs to handle.

• Quality thresholds are set explicitly. Minimum doesn't mean unfinished. The workflow has to work reliably. The interface has to be credible enough that customers attribute failures to the product idea. These are scope decisions and belong in the plan.

• Instrumentation goes in before launch. The events that measure the hypothesis have to be recorded from the first user, since the early cohort is small and cannot be re-run. An MVP that ships without analytics produces anecdotes.

• It goes to a narrow, reachable audience with a decision date attached. A specific segment the team can talk to directly gives better signal than a broad launch, and setting the review date in advance prevents the result from being evaluated whenever the numbers look most favorable.

What Tools Do Teams Use to Build an MVP?

• Backend and infrastructure services: Supabase and Firebase provide authentication, a database, file storage, and hosting without infrastructure work, while Vercel handles deployment and preview environments, removing most of the setup that would otherwise precede the first feature.

• No-code and low-code builders: Bubble, Webflow, and Retool produce working applications without a codebase, which suits validation phases where the product will be rebuilt regardless of the outcome and speed matters more than the final result.

• Validation and measurement tools: Maze runs structured tests against prototypes before code exists, Amplitude and Mixpanel record whether the hypothesis event occurred, and Hotjar supplies session recordings that explain the drop-offs the numbers show.

What Are the Key Characteristics of an MVP?

• Scope is set by a question. Include only the features needed to answer what the team is trying to learn.

• One complete path beats several partial ones. Depth on a single, well-built workflow generates usable evidence. Breadth across half-built features generates complaints about what's missing.

• Viability is a quality commitment. The release has to be good enough that its reception reflects the idea.

• It has a date on which a decision gets made. Without one, the MVP becomes the product by default, and the question it was built to answer stops being asked.

• It is built in the knowledge that it may be discarded. Accepting that possibility allows the shortcuts that make it fast.

• The audience is small and specific. A defined segment the team can contact produces interpretable results.

What Are the Benefits of Building an MVP?

• Evidence arrives while there is still money to act on it. Shortening the interval between an idea and its first contact with customers is the only way to preserve the option of trying something else.

• Observed behavior replaces stated preference. Customers describing what they would do is unreliable in a way that watching them use a working product is not, and only the second one is available from an MVP.

• The cost of being wrong stays bounded. A failed hypothesis costs the build, and the company continues. The same failure discovered after eighteen months of development often leaves a company with nothing to continue with.

• Prioritization discipline carries forward. The habit of asking what a feature is meant to prove outlasts the MVP phase and improves the decisions made once the product has customers.

• Stakeholders get true usage data. A working product with a measured early cohort is materially more persuasive to investors and internal sponsors.

What Are the Challenges and Trade-offs of Building an MVP?

• The MVP becomes the product. Planning a rewrite once demand is confirmed is the standard answer, and the rewrite competes for engineering capacity at exactly the moment customers are arriving and asking for features, so it is deferred repeatedly and the shortcuts harden into the architecture.

• Minimum gets read as permission to ship something rough. Setting explicit quality bars protects the validity of the test, and each bar adds scope and pushes the launch date, which erodes the speed advantage that motivated the approach.

• A negative result is hard to interpret. Pre-registering the success criteria and the audience makes the outcome readable, and it locks the team into a conclusion it may dislike, while the narrow audience that made the test clean also makes the finding difficult to generalize to the broader market.

• Some markets do not accept minimum products. Regulated industries and enterprise buyers require security review and integrations before any evaluation. Concierge approaches that deliver the outcome manually get around the build requirement, and they test demand without testing the economics, because the manual version carries costs the product would not.

What Is the Difference Between an MVP and a Prototype?