Software Growth

MVP (Minimum viable product)

An MVP is the smallest version of a product that lets you learn whether real customers want it, built with the least effort needed to find out.

An MVP is the quickest way to test a business idea with real customers. The point is learning, not shipping a stripped-down product. For founders with limited time and money, it is a discipline: build only what you need to answer the riskiest question, then decide with evidence.

Where the term comes from

MVP, despite the name, is not about creating minimal products.

Eric Ries / What is an MVP?

Eric Ries, who developed the lean startup method, defines an MVP around validated learning with the least effort. The minimum depends on the question. A prototype can test whether someone understands a workflow. A paid pilot can test whether solving that workflow is worth buying. Those are different experiments.

Match the experiment to the uncertainty. Fictional agency approval tool • Select a test; these are not mandatory launch stages Original worked example, informed by Eric Ries’s definition of validated learning.
Original worked example, informed by Eric Ries’s definition of validated learning. Source / framework reference.

What an MVP can look like

  • A landing page. Explain a specific promise and price, then invite people to join a clearly labeled waitlist. This tests interest, not retention.
  • A manual service. Do the work behind a simple interface before automating it. This tests whether the outcome matters.
  • A working product with one useful feature. Solve one painful job for a narrow group and observe whether they come back.

Fictional example: before coding invoicing automation, you could take five freelancers, build their invoices in a spreadsheet each week, and charge $29 a month. If four pay for two months, you have early evidence of willingness to pay. You still need to learn whether the service can become a repeatable business.

AI makes prototyping faster. Use the time to learn.

AI coding assistants and app builders can shorten the path from an idea to something a customer can try. Lovable's documentation describes generating and editing full-stack applications through natural language. Replit describes combining code generation, debugging, databases, and deployment in one environment, including for people outside engineering.

For a narrow workflow, a founder can now aim to put a usable prototype in front of customers in hours or days. That is a planning possibility, not a guaranteed timeline: unfamiliar integrations, complicated rules, and production requirements can still take substantial work. The useful change is that you can try more approaches before committing to one.

  1. Name the uncertainty. For example: will agencies use a shared approval page instead of chasing clients by email?
  2. Build only the experiment. Create one approval flow using sample data. Skip the billing engine and agency dashboard for now.
  3. Observe a real task. Ask an agency to use it on an upcoming approval. Watch where they hesitate and what they still do outside the tool.
  4. Change and test again. Use the shorter build cycle to respond to what happened, then test payment and repeat use.

A generated interface is a prototype. It becomes an MVP when you use it to test a business assumption with real customers. Before relying on it for paid work, check the promised workflow, access permissions, data handling, and recovery from failures. Faster code generation does not by itself establish product-market fit.

What if customers build the tool themselves?

The same tools are available to buyers. An operations team may build a private dashboard, approval tracker, or reporting script instead of subscribing to a small SaaS. In their July 2026 essay The Self-Driving Company, Amjad Masad and Scott Kennedy report that Replit replaced a seven-figure SaaS solution with an internal app. This is a vendor's account of its own experience, not evidence that every customer will make the same choice.

Our practical reading is that a product's competition can now include a custom tool that the customer can assemble cheaply. The risk is greater when your entire value is a simple workflow with little ongoing upkeep. It is less straightforward when customers need dependable integrations, shared permissions, support, or someone to own maintenance.

During customer interviews, ask what the buyer has already built, who fixes it when it breaks, and what would make paying you worthwhile. Test the value of the outcome and the work you take off their hands. A polished demo alone will not answer whether they prefer to buy or build.

Minimum lovable products and Jason Cohen's SLC

MVPs are too M and rarely V.

Jason Cohen / Your customers hate MVPs. Make a SLC instead. (August 22, 2017)

Cohen's alternative is SLC: Simple, Lovable, Complete. Keep the scope narrow, make it something customers want to use, and deliver the promised job end to end. His objection is to making customers tolerate an unfinished experience so the company can learn.

A minimum lovable product (MLP) puts similar emphasis on the first customer's experience. Brian de Haaff of Aha! writes about MLP explicitly; Cohen uses the SLC name. They are related approaches, rather than interchangeable labels with the same author.

Never guess at what they value.

Brian de Haaff / It Is Time for the Minimum Lovable Product (April 5, 2017)

For your MVP, this means choosing one reason someone would prefer using it. An approval tool might feel lovable because clients can approve without creating an account, the status is clear, and nobody has to send a reminder manually. Validate that experience with customers rather than adding decorative polish by default. The MLP guide explains how to set that bar without expanding scope.

Common mistakes

  • Building for months before talking to a customer, or generating a full app before defining the experiment.
  • Treating a convincing demo as proof of payment, repeat use, or dependable delivery.
  • Letting cheap implementation turn every idea into another feature.
  • Testing with friendly peers who do not have the problem you intend to solve.
  • Ignoring the buyer's existing spreadsheet, internal tool, or ability to build an alternative.

For bootstrappers

If your riskiest assumption is willingness to pay, test payment early through a paid pilot or a small subscription. If the uncertainty is usability, observe the workflow first. Decide what result would justify another iteration before you start building. A faster development cycle is useful when it shortens the time between a question and evidence.

Sources

Back to the SaaS glossary