What Is an MVP? How It Differs From a Prototype and a Pilot

An MVP (minimum viable product) is the smallest version of a product that real customers can actually use, built to answer one question: is this idea worth pursuing? So what is an MVP not? It isn't a half-finished product full of bugs, a clickable mockup (that's a prototype) or a custom build for a single client (that's a pilot).

I'm a freelance full-stack developer based in Denmark, and I build SaaS products and web apps for clients, so I make money when people decide to build. That's exactly why I'd rather you build the right thing in the right order than spend your budget on a first version that can't tell you anything.

MVP vs prototype vs pilot: the short answer

My rule of thumb: if you're not sure people get the idea, build a prototype. If you're not sure anyone will pay, build an MVP. If a specific customer wants to try it before signing, run a pilot.

If you're at the very start with a SaaS idea, my guide to building a SaaS from idea to paying customers covers everything from validation to launch. This post sticks to the concept itself, and to how you work out what your own MVP should be.

Where the term comes from

The term was popularized by Eric Ries, author of The Lean Startup. In a 2009 post on his blog, he describes the MVP as the version of a new product that lets a team learn the most about its customers for the least effort. He calls that kind of evidence validated learning: knowledge based on what customers do, not on what they say in interviews.

Each half of the name does a job:

• Minimum means as little as possible. Only what it takes to answer the question.
• Viable means it can survive in the real world. Real people can use it to solve a real problem, and it works well enough that they come back.

The trouble is that "minimum" sticks and "viable" gets forgotten. Henrik Kniberg, then at the Swedish consultancy Crisp, drew what's probably the best-known picture of the difference. Instead of shipping a wheel, then more parts, then finally a car, you ship a skateboard, then a scooter, a bicycle, a motorbike and finally a car. Every version gets the customer from A to B, which is what they needed all along.

Kniberg suggests replacing MVP with sharper terms: the earliest testable, earliest usable and earliest lovable product. As he puts it in Making sense of MVP, "Your 'viable' is my 'horrible'." One vague word hides very different expectations about quality, and that's where most of the confusion starts.

For a SaaS product, this means an MVP is small but whole. A customer can sign up, get the core job done from start to finish, and pay. It isn't a quarter of the big product.

What an MVP is not

Most misunderstandings come from mixing up scope and quality, or from using the word for something else entirely.

Not a half-finished product

A buggy MVP gives you bad data. If users drop off, you can't tell whether the idea failed or the login screen did. Cut the number of features, not how well they work. The feature that solves the core problem has to be good.

Not a full version 1

Plenty of feature lists labeled "MVP" are really a complete first release: user roles, reporting, integrations, a mobile app and an admin panel. Wanting all of that eventually is fine. It just isn't a minimum, and it delays the answer to the one question that matters. If you're struggling to cut, my MVP feature list of 12 things your SaaS can skip at launch should help.

Not a prototype

A prototype looks like the product, but it doesn't store real data and can't take on real customers. It's great for testing whether people understand a flow, and it's cheap to change. A positive reaction to a prototype is not a payment, though. People are polite in user tests, and saying yes costs them nothing.

Not a pilot

A pilot is a trial with one specific customer, often a larger company, for a set period and against agreed success criteria. It tells you whether the solution works inside that organization. If you sell to companies in the EU, a pilot with real personal data will usually also mean a data processing agreement under GDPR before you start. The risk is that the pilot slowly turns into a bespoke system, because the customer has needs nobody else shares. That can be good business, but it doesn't prove there's a market.

Not something you throw away

Some people use "MVP" for a quick and messy build that will be rewritten later. If that's the plan, call it a prototype and budget for building the real product afterwards. A coded MVP that works usually becomes the foundation for the next version, so the data model, security and framework should be chosen with that in mind.

Not every MVP needs code

The question decides the format, and many of the most important questions can be answered without a developer:

• A landing page with pricing and a sign-up button (often called a smoke test) shows whether people are interested enough to act.
• A concierge MVP, where you personally do the work the software will automate later, shows whether customers will pay for the outcome.
• A Wizard of Oz MVP looks like a finished product from the outside, but behind the curtain you're doing the work by hand.
• A no-code tool, or a spreadsheet plus a form, can serve your first customers if the workflow is simple.

I walk through these methods step by step in my guide on how to validate a SaaS idea before writing any code. The point here is that code isn't what makes something an MVP. Real customers using it to solve a real problem is.

Code becomes necessary when the product itself is the value: when customers log in and work in it every day, when data has to be shared between users, or when the manual version can't keep up with demand.

How to work out what your MVP should be

Order matters here. If you start with a feature list, you have nothing to judge the features against. Start with what you're least sure about instead.

1. Find the assumption that could sink the idea

Write down what has to be true for the idea to work. Say you want to build a tool that helps small accounting firms collect documents from their clients. You're assuming that chasing paperwork eats hours every month, that firms will move away from email and shared folders, and that they'll pay something like €49 a month. Pick the assumption that's least certain and would kill the idea if it's wrong. That's what your MVP should test.

2. Write the question, and decide what counts as a yes

"Will accountants pay for this?" is too vague. Decide up front what a yes looks like, for example five firms paying two months in a row. Without a threshold, every result starts to look "promising", and you learn nothing.

3. Pick the cheapest format that gives an honest answer

Go back to the table at the top. Testing interest? A landing page will do. Testing understanding? Build a prototype. Testing willingness to pay? Run a concierge or a coded MVP. Testing whether it works inside one organization? Run a pilot. Don't choose code because it feels more serious.

4. Cut it down to one end-to-end workflow

If the MVP needs code, describe the single path a new customer takes from sign-up to result, and build only that. I cover how to sort the wish list in practice in my guide on how to scope an MVP.

5. Decide in advance what you'll do with the answer

There are three outcomes: carry on and build further, change course (a different audience, price or problem), or stop. Write down what would trigger each. It sounds formal, but it protects you from pouring more money into an idea just because you've already spent some.

What a coded MVP needs on day one

Once an MVP is built in code, "viable" is where the money goes. The baseline is the same whatever the product does:

• Customers can sign up and log in securely.
• The core feature works end to end without you stepping in.
• There's a way to pay, even if it's a manual invoice at first.
• Each customer's data is kept separate, and everything is backed up.
• You're alerted when something breaks, so you don't hear it from customers first.
• Personal data is handled in line with GDPR from the first customer, which includes knowing where your data is hosted.

Most other things can wait until users ask for them. I usually build MVPs in Laravel, sometimes with React or Next.js for the interface, because they're widely used, well documented and easy for another developer to take over. It's not the only sensible choice, but it's one you won't regret as the product grows.

Cost depends mostly on how much sits inside that one workflow. If you want numbers, I've broken down MVP development cost in Europe with example budgets in euros.

When you shouldn't build an MVP yet

There are situations where you need neither an MVP nor a developer like me:

• You haven't spoken to a single potential customer. Start with conversations. They're free and fast.
• A landing page, a spreadsheet or a manual service can answer the question. Code would be an expensive detour.
• You're building an internal tool for your own company, where the users and their needs are known. There's no market to test, so you just need a solid first version. Shipping in small steps still helps, but the label doesn't matter.
• You have one large customer willing to pay for a solution. That's a pilot or a client project, and it should be agreed and priced as one.
• You expect the MVP to be finished at some point. It won't be. The whole idea is that you change it once you see how customers use it.

Next steps: from idea to first version

Before you spend money on development, make sure you can answer the basics. It makes the conversation with any developer, and the quote you get, a lot more precise.

If you can tick most of these, you're ready to talk about building. My page on SaaS development explains how I work, from a paid fixed-price discovery phase where you and I scope the MVP together, through launch and further development. You own the code from day one, and you deal directly with the developer writing it.

Frequently asked questions

What's the difference between an MVP and a proof of concept?+

A proof of concept (PoC) tests whether something is technically possible, while an MVP tests whether people will use it and pay for it. A PoC is usually an internal experiment with no real users, for example checking whether an integration or an AI model gives good enough results. When technical uncertainty is high, build a PoC first so the product doesn't rest on an assumption that fails.

What do MLP and MMP mean?+

MLP stands for minimum lovable product and MMP for minimum marketable product. Both try to pin down what "viable" should mean. An MLP stresses that early users should enjoy the product, not just tolerate it. An MMP is the first version you can market and sell broadly. The underlying idea is the same as an MVP: small scope, high quality in whatever you include.

Can I build an MVP myself with AI or no-code tools?+

Yes, for a prototype or an early test, tools like Lovable, Bolt or Bubble can take you a long way. The hard part starts when real customers log in, pay and store data. Security, data separation and long-term maintenance take experience. Use the tools to test demand, then have a developer review what you've built before real customer data goes into it.

What happens to an MVP after launch?+

It changes, often a lot. You watch how customers actually use it, what they ask for and where they drop off, then adjust. Some features get built out properly and others get removed. Plan time and budget for the months after launch, on top of the build itself. Launch is the start of the work on the product, not the end of it.