What is an MVP, and how do you build one?
An MVP (minimum viable product) is the smallest version of a product that can show whether people will use it and pay for it. Its job is to answer the most important question about the idea with as little work as possible. After launch, you build on what users do.
Håkon Kjelseth, CTO at Brink Studio
Updated · 6 min read
Where the term minimum viable product comes from
The term is usually credited to Frank Robinson of the firm SyncDev, who used it in 2001, according to Wikipedia. Steve Blank and Eric Ries brought it into the startup world, most of all through Ries' 2011 book The Lean Startup.
Ries defines an MVP as the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort (Startup Lessons Learned, 2009). His definition is about learning. It says nothing about how many features the product should have or how cheap it should be to build.
What an MVP is for
Every new digital product rests on assumptions, for example that people have the problem you think they have and that some of them will pay to have it solved. An MVP tests the riskiest of those assumptions with real users, so you don't spend the whole budget before you know whether the idea holds up.
The answer comes from behaviour. Someone telling you in an interview that they would use the app counts for little next to them downloading it, opening it again the following week and entering a card number. That is why an MVP has to be good enough for people to use properly.
We started work on Unveil, a shared disposable camera for weddings and parties, in July 2026. By September it had paying customers in 12 countries. Payments like that tell you more than any interview can.
How to decide what goes into an MVP
Start with one job the product does for the user. Picture a booking app for a physiotherapy clinic. The job is that a patient finds a free slot and books it. A loyalty scheme, chat with the therapist and support for several languages can wait until you can see that people book.
Next, pick one type of user to build the first version for. The booking app has patients and staff, and both groups want things. Early on, staff can often get by with a simple admin panel while patients get an app that works well.
Finally, decide which number will tell you whether it works, and do it before you start building. It might be the share of visitors who complete a booking, or how many people move from a free trial to a subscription. With the number agreed up front, it gets easier to turn down features that won't move it.
Common MVP mistakes
The most common mistake is putting too much into the first version. Every feature has to be designed, built, tested and maintained. A long feature list also makes it harder to see what made people stay and what made them leave.
Another is launching without measurement. You are then left with impressions and the odd message from a user, which are easy to read the way you want to.
You can also go too far the other way. An MVP that crashes or is hard to understand tells you little about the idea, because people leave over the execution. The first version can have few features, but the ones it has need to work.
It is also easy to start building before you have spoken to anyone in your target group. A handful of conversations can show that the problem looks different from what you assumed, and finding that out before the code exists is far cheaper.
Alternatives to try before writing code
Some questions can be answered more cheaply than with a working product. Each of these methods suits a different situation:
- Clickable prototype: designs that look and behave like an app. Useful when you want to see whether people understand the solution and can find their way around, or when you need to show the idea to investors.
- Landing page: a web page that describes the product and asks people to join a waiting list or pre-order. Useful when the question is whether enough people are interested.
- Manual service: the customer gets the result, but you do the work by hand behind the scenes. Useful when you want to find out whether people will pay for the outcome before you automate it.
What does it cost to build an MVP?
With us, a first version of an app, web app or custom system starts at NOK 150,000 excluding VAT, and it usually lands between NOK 150,000 and 500,000. The price depends mostly on the number of screens and features, and on whether users pay inside the product. Our pricing page explains what pushes the price up or down.
A first version usually takes two to four months. When we build an app, we test designs on the people who will use it before writing code, because a design is cheap to change. If you have an idea you would like an estimate for, send us a description and we will reply with what we think the first version should include.
What to measure after launch
Set up analytics before you launch. A tool such as PostHog shows where users drop off, which features they use and how many come back. We use PostHog in our own apps and set it up in new products as well.
If the product charges money, the share of users who go from free use or a trial to paying is the number that matters most. QuitNic, our app for quitting smoking, vaping and snus, came out in June 2025 and has been updated regularly since. Its paywalls are managed in Superwall, so we can test new versions of them without shipping a new release to the App Store.
A few weeks of data should tell you whether to keep building on what you have, change direction or drop the idea.