How to build an MVP: start small and test with real users

What is an MVP, and how do you build one?

An MVP, or minimum viable product, is the first version of a product that tests an idea with real users for the least amount of work, and you build it in this order: write the assumption, cut scope to the minimum, fix time and budget, set up measurement, then release to real users. We keep a short definition in the glossary under MVP.

The point is not to build the product cheaply. It is to learn whether you are building the right thing before spending the big budget. You cannot tell in a meeting room whether an idea works. Users open the product, try it, and come back or do not. An MVP gets you that answer the shortest way.

What is an MVP not?

An MVP is not a half-built product, a demo, or a weak version of every feature.

• Not half-built: it does a few things end to end, without errors. A user can start a task and finish it.
• Not a prototype: a prototype shows the idea and often runs on fake data. An MVP goes to real users and produces real data.
• Not a cheap version: it is 100 percent of three features, not 50 percent of ten.
• Not throwaway code: if it works, you build on it. Code, data model and accounts must be set up properly from day one.

The last point is the one people skip. Code written in a rush "because it is only an MVP" becomes the biggest obstacle the moment the product takes off.

How do you cut MVP scope?

You cut MVP scope by putting every feature into one of three buckets: must-have, later and never. Must-haves are what the assumption cannot be tested without. Later is what you add if the product works. Never is the ideas that made the list but nobody actually asked for. For each feature, ask one question: can the user complete the main task without it? If yes, it is not a must-have. In most lists, more than half the features land in later.

How long does an MVP take?

It depends on scope, but a well-cut MVP usually ships in a few weeks to a few months. If it takes longer, it has probably stopped being an MVP. A first version that takes six months means six months of learning nothing. We set the date together with the scope, not after it. If the must-haves do not fit, we do not move the date. We cut again. That is how an end date actually holds.

How do you set an MVP budget?

Set the budget by asking how much you are willing to spend to learn whether the assumption holds. Budget first, scope second. Writing every feature down and then asking for a price turns the MVP into a full product. The items that raise the price most are several user types, integrations, payments, multiple languages, an admin panel, and separate web and mobile interfaces. The factors on the mobile side are covered in what mobile app cost depends on. Keep part of the budget for fixes and additions after launch. Early feedback will change something.

Should an MVP be a web app or a mobile app?

If the assumption does not need anything phone-specific, a web MVP usually ships faster: no store review, instant updates, shareable by link. If notifications, camera, location or offline use are part of the assumption, you need a mobile app. Store rules still apply. Apple's review guidelines state that apps offering too little functionality can be rejected, so a store MVP must be a real, working product. One codebase for both platforms saves time on most MVPs. See native or Flutter for that decision.

What should you measure in an MVP?

Measure one main number that shows whether the assumption holds, plus a few supporting ones. In the booking example that could be bookings made in the first month and the share of customers who book a second time.

• Start: how many people opened the product and began the main flow.
• Completion: how many finished it, and where the others dropped off.
• Return: whether users came back after a week or a month.
• Conversations: short calls with five to ten users. Numbers show what happened, conversations show why.

Write the success threshold before launch. Without one, any result gets read as a success.

What does the roadmap after an MVP look like?

After an MVP you make one of three calls from the data: continue, change or stop. Continue means re-ranking the later bucket by what users struggled with or asked for most. Change means rewriting the assumption and running the loop again with a smaller scope. Stop is also a result, learned without spending the big budget. Two items belong on every roadmap: shortcuts taken for speed, listed and closed before growth, and infrastructure such as hosting, backups and monitoring. Each new phase gets its own definition of done.

How does RadKod build an MVP?

We start by cutting scope with you. On the first call we write the assumption and sort the features. Then comes a one-page quote with scope, price, date and what is out of scope, followed by a signed definition of done. The code repository, server, domain and store accounts are in your name from day one, so if the MVP works, the product is yours to build on. Bugs in the 30 days after delivery are fixed free. The person you talk to writes the code, which is why we can price each bucket on the spot.

See custom software for web products and mobile app development for phones. If you are collecting several quotes, read how to compare software quotes.