How to build an MVP that tests your idea

MVP development means building a minimum viable product: the smallest real version of your product that people can actually use, and that tells you whether the idea deserves more of your time and money. Done well, it can save you months of building the wrong thing.

We wrote this for founders, product owners and business leaders with an idea for a new app or platform who want to test it without betting everything on the first attempt.

What is an MVP and what is it not?

An MVP is a working product that real people use, and it does one job well enough for them to rely on it. It's small on purpose, because you're building it to learn. You put it in front of people to find out something you couldn't discover any other way.

A few common mix ups are worth clearing up early.

• Small doesn't mean cheap and cheerful. Every part you build should be well made. You just build fewer parts.
• A demo won't do the same job. A demo shows off an idea. An MVP gets used for real tasks, with real data, by people outside your team.
• Security still matters from day one. If it stores personal data or takes payments, it needs proper sign in, encryption and access rules right from the start.
• Launch is the beginning. Your MVP starts a cycle: release it, measure what happens, improve it, and repeat.

Which question must your MVP answer?

A strong MVP is built around one question. Write yours down before anyone designs a single screen. You'll find it usually fits one of these groups.

• Will people use it? For example: will warehouse staff log deliveries on a phone instead of on paper?
• Will people pay for it? For example: will small clinics pay a monthly fee to book appointments online?
• Can it be done? For example: can we match data from two older systems quickly enough to be useful?

Next, turn that question into a test with a result you can check. "People like it" won't tell you much. "Within six weeks of launch, at least a set number of the invited users complete a booking without help" will. Pick that number before launch, based on what would make the next stage worth paying for. If you wait until the results are in, it's far too easy to talk yourself into calling almost anything a success.

Before you build, write down the result that would make you stop. Without it, you're building a product and hoping for the best.

Why start with a discovery phase?

Product discovery is a short stage before the build. You check your assumptions, map the main steps a user takes, and agree what goes into the first version. It usually takes one to two weeks, and since nothing has been built yet, it's the cheapest moment you'll ever have to change your mind.

A typical discovery phase covers:

• Conversations with likely users, to hear how they deal with the problem today and what it costs them.
• A map of the core path, the handful of steps a user takes from first arriving to getting something useful.
• A look at what's already out there, including rival products and any systems your MVP has to connect to.
• A scope list and a rough plan, so the team and whoever is paying agree on what's in and what waits.
• A short list of risks, such as data rules, integrations or technical unknowns, each with a plan.

At the end you get a written summary that's yours to keep, whoever ends up building the product. Our software development process describes how discovery leads into design and the first sprint.

How do you cut scope without losing the point?

Scope is the list of things the product will do. When you build a minimum viable product, cutting that list is the hardest part, and the one that pays off most. Here's a simple rule that works: a feature only counts as a must have if you can't answer your one question without it.

Go through every idea and put it on one of two lists. The example below is for an imaginary appointment booking app.

A few tricks make the cutting easier:

• Do some jobs by hand at first. Someone on your team can approve accounts or send out reports while you find out whether anyone needs them automated.
• Use proven services for the common parts. Sign in, payments and email can come from established third party providers, so you don't build them from scratch.
• Serve one type of user first. Every extra role adds screens, rules and tests.
• Hold on to the later list. Nothing gets thrown away. Once you know more, it becomes your plan for what comes next.

Prototype or MVP: which do you need?

People often use these two words as if they meant the same thing. They answer different questions, though, and plenty of projects do well with both: a prototype first, then the MVP.

A prototype is cheap to change, which makes it the right place to try out layout and wording. An MVP shows you how people behave, and that matters, because what someone tells you in a friendly test session and what they do on a busy Monday morning are often two different things.

How long does MVP development take?

Most MVPs take a few months from the first conversation to launch. Your real figure depends on the scope, how many platforms you need, which other systems it connects to, and how quickly your side can make decisions. The stages below give typical ranges, so treat them as a guide rather than a promise.

Typical MVP stages and broad ranges

1. DiscoveryQuestion, core path, scope.1 to 2 weeks
2. DesignPrototype and user tests.2 to 4 weeks
3. Key stepBuildSprints with regular demos.6 to 12 weeks
4. Test and launchChecks, then first users.1 to 2 weeks
5. LearnMeasure against the test.4 to 8 weeks

These are broad ranges for a single web product. Extra platforms, integrations or strict data rules will add time.

The build happens in sprints, short working cycles that usually last two weeks, each ending in a demo of working software. Those demos keep everyone honest about scope. You see what actually exists, and if something is taking longer than it's worth, you can move it to the later list while that's still cheap to do. For a view of what drives the budget, read our guide on how much custom software costs.

How do you choose technology that can grow?

Many founders worry that if the idea works, they'll have to throw the MVP away and rebuild from scratch. A few sensible choices early on make that far less likely.

• Pick popular, well supported tools. React for the web front end (what people see and click), Node.js or something similar for the back end (the server and business rules) and PostgreSQL, a widely used database, are all safe choices. Lots of developers know them, so you'll never struggle to find help.
• Start with one well organised application. Splitting a small product into lots of separate services too early costs more and gives you nothing back.
• Use managed cloud hosting. Services on AWS or Azure take care of backups, updates and spikes in traffic, so your team can spend its time on the product itself.
• Set up CI/CD from the start. CI/CD is an automated pipeline that tests and releases every change, which keeps quality steady as the product grows.
• Build clean APIs. An API is a connector that lets systems swap data. A tidy one makes it much easier to add a phone app or connect a partner's system later.

If you're weighing up web against phone apps for the first version, our guide to native or cross platform apps explains the choice in plain terms.

How much early choices affect later growth

• Data model and database choiceHigh
• Security and access rulesHigh
• Automated tests and releasesMedium
• Visual design detailsLow

This is our usual view. You can restyle screens at any time, but changing how data is stored gets harder with every month of real use.

How do you know if your MVP worked?

Start with the test you wrote down before the build, and judge the MVP against that first. Once you have that answer, look at the wider picture.

• Activation: how many of the people who sign up complete the core task at least once.
• Return use: how many come back over the following weeks without a reminder.
• Willingness to pay: real payments or signed agreements, which count for far more than people saying they'd pay.
• Where people drop out: the step where most users give up.

Set up simple analytics and error monitoring before launch day. If you only start measuring once complaints come in, you'll have missed the early data that tells you the most.

What should you do after launch?

Once the results are in, you really have a choice between carrying on, changing course and stopping.

• Continue. If the test passed, pull the most requested items from the later list into the next few sprints, and shore up the parts that will need to handle more users.
• Change direction. If people used it, but not the way you expected, adjust the question, the audience or the core job, and test again.
• Stop. If the test failed and no change looks promising, you still keep everything you learned, and you've spent a fraction of what a full build would have cost.

Whichever way you go, hang on to the habits that made the MVP work, especially writing the question down and holding regular demos. If you plan to hire a team to take the product further, our guide on choosing a software development company lists the questions worth asking.

How does V6 Cube build an MVP?

We start with a short discovery phase where we agree the one question, the core path and the scope with you. Then you get a fixed estimate before any build work begins, and projects usually start within one to two weeks of agreeing the plan. During the build you'll see working software in a demo every sprint, and you're free to move features between the must have and later lists as you learn.

You own all the code and designs from the start, and we're happy to sign a confidentiality agreement before you tell us your idea. After launch, you can carry on with a dedicated team or a care and support plan. Our engagement models explain how each works. Read more about our custom software development services, or see the products we have built for clients in over 40 countries. Testing an idea for schools or charities? See how we build education software and software for nonprofits.