People who come to us with an idea for an app or a platform usually already picture the final version: social login, dashboards, notifications, payments, chat, analytics, maybe an iPhone app and an Android app too. That's natural, and it's also the fastest way to spend a lot before knowing whether the idea works.
The alternative has a precise name: MVP. In this article we look at what it is, what it isn't, how to decide what goes into it, and why it's almost always the right place to start.
What an MVP (really) is
MVP stands for Minimum Viable Product. It's the simplest version of your project that genuinely solves the main problem it exists for, well enough that real people can use it. Not every feature you have in mind: only the ones without which the product wouldn't make sense.
The point of an MVP isn't just saving money. It's learning: getting the product into users' hands as early as possible and finding out what they use, what they ignore and what they ask for. That's information no meeting or project document can give you.
What an MVP is not
The term is often used loosely, and the confusion is costly. An MVP is not:
- A badly built version: it's smaller, not flimsier. What's there has to work well
- A mockup or a demo: people must be able to actually use it, not just look at it
- A throwaway project: built properly, it's the foundation you keep developing on
- A "discount" product: it costs less because it does fewer things, not because they're rushed
Why starting small pays off
- You spend less up front, when the risk is highest and certainty is lowest
- You go live in weeks instead of months, and start gathering users and feedback
- You find out early whether the idea holds up: better after a small investment than a large one
- You avoid building features nobody uses, and there are surprisingly many of them
- You make the next decisions based on real data, not assumptions
How to decide what goes in (an example)
The rule is easy to state and hard to apply: for each feature, ask whether the product still solves its main problem without it. If the answer is yes, that feature can wait. Let's take an example: a platform for booking classes at a gym.
| Feature | In the MVP? | Why |
|---|---|---|
| Class schedule and booking | Yes | It's the reason the product exists |
| Sign-up and login | Yes | You need to know who booked what |
| Confirmation email | Yes | Cheap to build and cuts down on forgotten bookings |
| Staff panel | Yes, bare-bones | Seeing and managing bookings is enough, no reports |
| Online payments | Later | At first people can pay at the front desk, as they already do |
| Native iOS and Android apps | Later | A web app already works well on smartphones |
| Analytics, chat, loyalty program | Later | Only useful once there are active users to analyze |
The result is a product that does one thing, does it well, and that the gym can start using with its members right away. Postponed features don't disappear: they go on a list, and get built when the data says they're needed.
How much an MVP costs
It depends on how many features survive the cut, but the order of magnitude is very different from the full product. A simple MVP web app usually starts at a few thousand euros, while the "everything included" version of the same project can easily multiply that figure. We collected the most common price ranges in this guide:
A practical tip: even for an MVP, budget for the costs that continue after launch (hosting, database, maintenance) and set aside a little for version two. The first release is the start, not the finish line.
The most common mistakes
- Adding "just one last feature" before launch, over and over again
- Going straight for a native app when a web app would be enough to validate the idea
- Polishing the visuals endlessly while neglecting the main flow
- Launching with no way to collect feedback: no data, no learning
- Treating the MVP as a throwaway experiment and building it without solid foundations
The second point deserves emphasis: many MVPs start as web apps precisely because they're faster to build and update, and they work on any device. A native app can come later, once it's clear it's needed. We covered it here:
How we build an MVP
In our method — Strategy, Design, Build, Launch — the most important work on an MVP happens in the first phase: together with you, we line up every feature you have in mind and decide which ones are truly essential. Then we design and build only those, properly, on a foundation made to grow. Our MVP web apps start at €3,500, and we set the final price in a free, no-commitment discovery call. If you have an idea and don't know where to begin, tell us about it: the first step is figuring out the smallest version worth building.
Tell us about it: we'll help you work out whether you need a website, a web app or an app — without pushing the pricier option if you don't need it.