A minimum viable product, or MVP, is the first version of a product that is good enough for real people to use or pay for, and nothing more. It is not a mockup and not a finished product. It is the least you can build to find out whether customers actually want what you plan to sell.

The term comes from software startups, but it applies to anyone launching something new. A creator testing a paid course, a brand trying a new candle line, a founder paying a freelancer to build an app: all of them face the same question. How little can you make before you know if the idea works?

What is a minimum viable product (MVP)?

An MVP is a working product with the smallest set of features that still delivers the core promise to a real customer. Each word counts. Minimum means you cut everything that does not serve the main promise. Viable means it must actually work and solve the problem, even if roughly. Product means someone can use it or buy it, not just look at it.

The goal of an MVP is learning, not revenue. You release it to measure one thing: do people use it, pay for it, come back to it? The answer decides whether you build more, change direction or stop.

What an MVP is not:

  • Not a prototype. A prototype shows how something could look or feel. Nobody relies on it. An MVP is used by real customers in real conditions.
  • Not a proof of concept. A POC checks whether something is technically possible. An MVP checks whether people want it.
  • Not a cheap version of the final product. A bad MVP is a full product with every part done badly. A good MVP is a small product with one part done well.

Related vocabulary you will hear: MLP (minimum lovable product), which stresses that the first version should still feel good to use; beta, a pre-release version given to a limited group; and pilot, a test run with one client or one market.

Why it matters

Most new products fail because nobody wants them, not because they were badly built. An MVP moves that discovery to the start, when it is cheap, instead of the end, when the money is gone.

Take a founder who wants to sell a meal-planning app to busy parents. An agency quotes 30,000 dollars and five months for the full version: recipes, shopping lists, a family calendar, nutrition tracking and a mobile app. Instead, she builds an MVP in three weeks for 1,200 dollars: a simple web page, a weekly meal plan sent by email, and a checkout for a 9 dollar monthly plan.

She sends 2,000 visitors to the page through her newsletter and a few posts. 60 people pay, a 3% conversion rate. After a month, 45 are still subscribed. That is a clear signal: the core promise (someone plans my week for me) is worth paying for. She now knows what to build next, and she has 405 dollars of monthly revenue to show an investor.

If only 4 people had paid, she would have lost 1,200 dollars and three weeks, not 30,000 dollars and five months. That gap is the whole point of an MVP.

How it works

Building an MVP follows a short loop: decide what you want to learn, build the least that teaches it, measure, then decide.

  • Write the core promise in one sentence. "Busy parents get a week of dinners planned in two minutes." Every feature must serve this sentence or wait.
  • Pick the riskiest assumption. Usually it is "people will pay for this", not "we can build this". Your MVP exists to test that assumption first.
  • Define success before launch. Choose one number and a threshold, for example "at least 30 paying customers out of 1,500 visitors in 30 days".
  • List every feature, then cut. Keep only what is needed to deliver the promise once. Logins, dashboards, settings and integrations usually wait.
  • Build with the fastest tools available. A no-code tool, an online store, a spreadsheet and manual work behind the scenes are all valid. Customers care about the result, not the stack.
  • Launch to a small, real audience. Your email list, your followers, a niche community. Not your friends, who will be kind.
  • Measure and talk to users. Numbers tell you what happened. Five short calls with buyers tell you why.
  • Decide. Build more, change one variable and test again, or stop.

A common variant is the concierge MVP: you deliver the service by hand to the first customers before automating anything. Another is the pre-sale MVP: you take pre-orders before the product exists and only produce it if enough people pay.

Benchmarks and examples

There is no universal number, but some ranges help you judge your results.

  • Time to build. A well-scoped MVP usually takes 2 to 8 weeks. Past three months, it is probably no longer minimal.
  • Budget. For a small business, 500 to 10,000 dollars is typical, depending on how much is custom code. A freelancer quote above 20,000 dollars for a "first version" deserves a second look at the scope.
  • Conversion on a paid offer. From a warm audience (your own list), 2% to 5% of visitors buying is a solid signal. From cold traffic, 0.5% to 2% is common.
  • Retention. For a subscription, keeping 60% or more of first-month buyers after 30 days suggests real value.

Typical situations:

  • A creator sells a course before recording it: an outline, a sales page and a price. With 40 sales, she records. With 3, she refunds and rethinks.
  • A skincare brand launches one serum in one size before a full range of twelve products.
  • A small store tests a new product category with 5 items bought in small quantities before ordering 500 units.

Common mistakes

  • Building too much. Adding "just one more feature" before launch delays the only thing that matters: real feedback.
  • Shipping something broken. Minimum does not mean unusable. If checkout fails or the core feature crashes, you learn nothing about demand.
  • No success metric. Without a number decided in advance, any result looks encouraging and you keep going by default.
  • Testing on the wrong people. Friends and family say yes. Strangers who pay are the only honest signal.
  • Treating the MVP code as final. Shortcuts taken to go fast create technical debt. Plan to rebuild parts once the idea is proven.

Best practices

  • Test demand before building. A landing page with a price and a checkout can validate interest before a single line of code.
  • Charge from day one. Free sign-ups are cheap. A payment, even 5 dollars, is proof.
  • Do things manually first. Send emails by hand, pack orders yourself, answer every question. Automate only what repeats.
  • Keep one metric in view. Paid conversions, weekly active users or repeat purchases, but just one at a time.
  • Write down what you cut. Those cut features become the start of your product roadmap, ordered by what users actually ask for.
  • Set a deadline. Decide the launch date first and fit the scope to it, not the other way around.

In Roctify

Roctify is a practical place to run a commerce MVP without writing code. On the Free plan, you can publish a link-in-bio page or a store with up to 10 products and a built-in checkout, so you can put a real price in front of real buyers the same day. Payments go through Stripe, PayPal or cash on delivery, with 0% transaction fees on every plan, so a small test does not lose money to platform commissions.

Digital products and courses are delivered automatically after payment, which suits pre-sales and course MVPs. Discount codes help you reward your first buyers, and on the Creator plan you can collect emails with forms and follow up with the people who showed interest. When the idea works, you keep the same catalog, customers and orders and grow into a full storefront with a custom domain.

FAQ

How much should an MVP cost?

It depends on the product, but for a small business most MVPs cost between 500 and 10,000 dollars. If you can test the idea with an online store, a sales page or manual work, the cost can be close to zero. Spend on what proves demand, not on polish.

What is the difference between an MVP and a beta?

A beta is a stage in a release, usually a nearly finished product given to a limited group to catch bugs. An MVP is a strategy: the smallest product that tests whether the idea has value. An MVP can be released as a beta, but a beta is not always minimal.

When should I move past the MVP?

Move on when you hit the success metric you set before launch and customers keep asking for more. At that point, rank the requested features, fix the shortcuts that hurt reliability and plan the next version. If the metric is far off after two or three iterations, change the offer or stop.