What Is MVP Development? A Guide for Founders

What is MVP development? It means building the smallest working version of a product that real users can use, so you can test the one assumption your business depends on. The meaning of MVP development is in the goal, not the size. You build to learn whether people want the thing and will pay for it. You do not build to show every feature you have planned.

An MVP is an experiment that customers can use, and often pay for. This guide explains what the term means, how an MVP differs from a prototype or a proof of concept, and how to tell if you need to build one yet.

What “minimum”, “viable” and “product” mean

Eric Ries defines the minimum viable product as the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort. In the same post he writes that the MVP, despite the name, is not about creating minimal products.

That sentence surprises most founders. Take the three words one at a time:

• Minimum applies to scope. You cut every feature the test does not need.
• Viable means a real user can get a real job done with it. A screen that only works in a demo is not viable.
• Product means people use it in their own work or life, with their own data. You watch what they do, not what they say.

Validated learning is the output. The Lean Startup site calls it the unit of progress and puts it inside a build-measure-learn loop. In plain terms: you write down what you believe, you build only enough to test it, and you measure the result.

MVP vs prototype vs proof of concept vs version 1

Agencies use these words loosely, so founders compare quotes for different things. This table is how I separate them.

A proof of concept removes technical risk. A typical example is checking that a third-party API returns what you need, or that a model is accurate enough on your data. A prototype removes usability risk. An MVP removes market risk. If you are unsure which risk is the biggest, that is the first thing to work out.

Three ways to build an MVP

Not every MVP is software. Pick the cheapest form that still answers your question.

1. Smoke test. A landing page that describes the product, with a sign-up or pre-order button. Ries describes a feature his team spent two weeks on that nobody wanted, and says a simple AdWords smoke test would have shown that first. A smoke test measures interest. It does not tell you whether the product works for people.
2. Manual service (concierge or Wizard of Oz MVP). You deliver the result by hand. In a concierge MVP the customer knows a person does the work. In a Wizard of Oz MVP the product looks automated, but a person works behind the screen. Paul Graham describes how early startups did things that do not scale to win their first users. The founder does the matching, the onboarding or the reporting personally. You learn exactly what the job involves before you write code.
3. Software MVP. A working app that does one core job end to end. This is what most people mean by “MVP development”, and it is what an agency builds.

My view: many founders jump to option 3 too early. If your test is “do people want this”, options 1 and 2 often answer it in weeks and cost very little. Build software when the job needs software to work at all, or when manual delivery stops you from learning anything new.

What MVP development looks like as a project

When you hire a team for MVP development, the work usually has five parts:

1. Discovery. Write down the user, the job, the riskiest assumption and the metric that will prove or disprove it.
2. Scope. List features, estimate effort and draw a cut line. Everything below the line goes on a “not in v1” list. Our guide on how to scope an MVP walks through this step by step.
3. Build. Short cycles with a working demo you can click every week or two.
4. Launch. Real users, real data, analytics on the events that measure your metric.
5. Measure and decide. Keep going, change direction or stop.

We run discovery as a short sprint first. After that, the build is fixed-scope, so you know what you get before you commit. Teams that skip discovery tend to discover the scope during the build, and that is the expensive place to find it.

The technology choices also happen early. If you are building a subscription product, our article on the SaaS MVP tech stack covers the trade-offs.

What can be minimal and what cannot

“Minimum” applies to features. It does not apply to the quality of the parts you ship. This is where I see the most confusion.

You can cut freely:

• Extra user roles, team accounts and settings pages
• Integrations nobody has asked for yet
• Native mobile apps, if a web app works on a phone
• Dashboards, if a weekly export answers the question
• Self-service billing, if you can send invoices by hand

You should not cut:

• Security basics. Safe sign-in, access control, secrets kept out of the code.
• Data protection. Under the GDPR, a controller must build in data protection by design and by default. That duty does not wait until version 2.
• Backups and a restore you have tested. Early customers forgive missing features. Lost data is much harder to forgive.
• Error tracking and analytics. Without them, you cannot measure the thing the MVP exists to measure.
• Code you own. The repository and cloud accounts should be in your name from day one.

My rule for every MVP is simple. Decide early which data you must never lose and which actions you must be able to trace. Everything else can be rough.

Do you need to build software yet?

Use this checklist before you ask anyone for a quote. If the first four are not true for you yet, spend time on discovery first.

• I can name one type of user in one sentence
• I have spoken to at least a handful of them about the problem, not about my idea
• I can write the riskiest assumption as one testable sentence
• I know which number, measured after launch, would prove it wrong
• A landing page or a manual service cannot test that assumption
• The core job needs software to work at all (for example, real-time data, many users at once, or calculations a person cannot do by hand)
• I have a budget for the build and for a few months of changes after launch
• I know who will maintain the code after the first release

If all eight are true, you are ready for MVP development. If the first four are true but not the fifth, run a smoke test or a manual service first. It is faster and costs far less.

Common mistakes

Building the version 1 product and calling it an MVP. If your MVP has ten features, it tests ten things at once and you will not know which one worked.

Building a prototype and calling it an MVP. A clickable mock-up tells you whether people understand the flow. It does not tell you whether they will come back next week.

No metric. If you did not decide before launch what result means “keep going”, every result will look like success.

Treating the MVP as throw-away code. Some teams plan to rebuild after launch. In practice, the MVP code often stays in production for years. Build the core properly and keep the scope small instead.

FAQ

How long does MVP development take?

It depends on the scope, so treat any number given before discovery as a guess. A short discovery sprint gives you a fixed scope and a timeline you can plan around.

Is an MVP the same as a beta?

Not quite. A beta usually means a version 1 product that is almost finished and open for testing. An MVP is deliberately incomplete. It tests one assumption.

What are the main types of MVP?

The three forms above cover most cases: a smoke test (landing page or pre-order), a manual service (concierge or Wizard of Oz) and a software MVP. A single-feature MVP is a software MVP with the scope cut to one job, which is what we recommend in most builds.

Can an MVP be built with no-code tools?

Yes, if the tool can do the core job and you accept that you may rebuild later. Check where the tool stores your data and whether you can export it.

What happens after the MVP?

You look at the metric and decide. If the assumption held, you move items from the “not in v1” list into the product, one at a time, based on what users ask for.

Next step

If you have an idea and want an outside view of whether it needs software yet, book a free 30-minute call. If you are ready to build, see how our MVP development works, from discovery sprint to launch. For a second opinion on an existing quote or plan, our technology consulting covers scope and stack reviews.