Prototype vs MVP vs product: what's the difference

Three stages, three different questions

People use these words loosely, and that is how founders end up launching a prototype to paying customers. The cleanest way I know to separate them is by the question each one answers.

• A prototype answers: does this idea make sense to people? It can be fake underneath. Hard-coded data, a login screen that lets anyone in, a payment button that goes nowhere. That is fine, because nobody's money or data is at stake.
• An MVP (minimum viable product) answers: will real people use this, and will they pay? It can be small, but it has to be real. Strangers sign up, their data is stored, and money changes hands.
• A product answers: can this keep working as a business? It is what an MVP becomes once people rely on it. It needs support, monitoring, backups and a safe way to ship changes.

The jump from prototype to MVP is the one that catches people out. The screens can look identical. What changes is everything underneath.

What a prototype is for

A prototype is a tool for learning. You show it to potential users, watch where they get stuck, and find out whether the problem you are solving is one they care about.

Good prototypes are fast and disposable. I would rather spend two days on a prototype and throw it away than spend two months building the wrong thing properly. Before AI tools, that meant Figma and a clickable flow. Now it often means a working app from Lovable, Bolt or v0, built in an afternoon.

That is a genuine step forward. A working prototype gets far better feedback than a static mock-up, because people can type real things into it and see what happens.

The risk is that it looks finished. A prototype built with an AI tool has a real database, real pages and a real URL. It is very tempting to share that URL with the first customer who asks.

What an MVP is for

The MVP is where you test the business, not the idea. That needs real behaviour from real people, which means the app has to work when nobody is watching.

"Minimum" is about scope, not quality. An MVP should do one thing, for one type of user, and do it reliably. If you are building a booking tool, the MVP might handle one kind of booking with card payment and nothing else. No team accounts, no integrations, no admin dashboard beyond what you need to run it by hand.

What it cannot skip is the plumbing that protects users and money:

• Login that works on the live domain, including password reset.
• Rules that stop one user reading another user's data.
• Payments that are confirmed by the payment provider, not by a page loading.
• Emails that actually arrive. Supabase, which sits behind many Lovable and Bolt apps, allows only 2 auth emails per hour without your own SMTP settings, so a launch day of sign-ups can stall on confirmation emails.
• Basic error handling, so a failure shows a message instead of a blank screen.
• Enough analytics to answer the question the MVP exists to answer.

If you want help deciding what goes in, the MVP scope tool walks through it.

What makes it a product

An MVP becomes a product when people depend on it. The moment a customer would lose money or work if your app went down for a day, the job changes.

A product needs things nobody notices until they are missing:

• Backups you have tested restoring, not just switched on.
• Monitoring that tells you about errors before a customer emails you.
• A staging copy, so changes are tested somewhere other than in front of users.
• Support, even if that is just you answering an inbox within a day.
• Code someone other than the original author can change safely.

None of this is glamorous. It is the difference between a side project and something you can charge a business for.

Real examples of each stage

Here is how one idea might look at each stage. Take a hypothetical marketplace that matches street food traders with the markets and events that host them. It is similar in shape to FindPopups, a client marketplace I designed and built, but the stages below are illustrative, not its history.

Prototype. A map with a dozen hard-coded vendors, a host profile page, and a "request booking" button that sends you an email. Built in a day or two. You show it to ten vendors and ten hosts and listen.

MVP. Real sign-up for vendors and hosts, profiles stored in a database with proper access rules, a booking request flow with notifications, and a way to take a fee. Built in weeks, not months. Launched to one city.

Product. Vendor and host dashboards, payouts, reviews, moderation, an admin panel, analytics on what drives repeat bookings, and the operational tooling to support it all. Built over months, shaped by what the MVP taught you.

Side by side

Where AI-built apps sit

Lovable, Bolt, v0 and Replit have blurred the line between prototype and MVP, because what they produce runs. That is a good thing. It also means the label depends on what has been done to the app since, not on the tool.

The tools are honest about this. Lovable's security docs say its scans cannot guarantee complete security and recommend a professional review for apps handling sensitive data. Lovable's Deep scan, which looks at your app's own logic, permissions and data, does not run automatically as you work: you start it yourself, apart from a few narrow cases such as scheduled scans on Enterprise plans.

In practice, an AI-built app is usually a strong prototype that needs a focused round of work to become an MVP. Not a rebuild, in most cases. A review of access rules, payments, error handling and the main user journeys, then fixes in that order.

I cover the full path in the prototype to product guide, and there is a tool-specific version for taking a Lovable app to production.

How to tell which one you have

Ask yourself these questions about your app as it is today:

If you answered no to the first three, you have a prototype. That is not a criticism. It means the next step is clear. If you are a yes on those but a no on the last three, you have an MVP that is not yet ready to become a product.

Moving from one stage to the next

From prototype to MVP, cut scope before you add quality. Pick the one journey that proves the business, make that solid, and leave the rest out. Then work through getting your AI-built app ready for real users, adding Stripe properly if you are charging, and setting up analytics so you can tell whether it is working.

From MVP to product, the work shifts to operations: backups, monitoring, staging and code that others can maintain. Most of that is boring, which is exactly why it gets skipped.

If you would rather have someone do the prototype-to-MVP step with you, my Rescue Sprint covers it, and a Validation Sprint is the place to start if you are still at the idea stage.