What is an MVP and how to build the first version of your idea

What a minimum viable product is, how to decide what goes in the first version, what drives its price and who to build it with.

By Bruno Varela · October 26, 2026 · 12 min

Illustration: a paper sketch of a screen, linked by a dotted line to a phone showing a simple first version of the app, next to idea, launch and metrics icons.

An MVP (minimum viable product) is the simplest version of your idea that already solves someone's main problem and that you can put in the hands of real customers. It isn't a mockup or a pitch deck: it works, people use it, and it tells you whether it's worth investing more. It makes sense when you have an idea and you still don't know if people will use it or pay for it.

Here we cover what an MVP is and isn't, when it makes sense, how to decide what goes in the first version, what you shouldn't cut, what drives its price and who to build it with. If you already have the idea, tell us about it in three steps in the quote tool.

En corto

An MVP solves one problem for one type of user, end to end, and launches so you can learn from real customers.
The hard part isn't building it: it's deciding what stays out of the first version.
You cut features, not security: accounts, data and code in your name are there from day one.
What drives the price most: how many types of users, whether it takes payments, whether it goes to the app stores and what it connects to.

What an MVP is (and what it isn't)

MVP stands for «minimum viable product». Every word matters:

Product. Something people actually use, not a drawing of how it would look.
Minimum. Only what's essential to solve the main problem. Everything else waits.
Viable. It works well and feels trustworthy, even if it does only a few things.

It often gets confused with two other things:

A prototype is a set of screens that look real but don't save anything. It's for testing whether people understand the idea before writing code.
An MVP already works: it has accounts, stores information and solves the problem, even if in a simple way.
The full product is what the MVP becomes over time, once you know what your users ask for.

From sketch to product: a prototype to see if the idea makes sense, an MVP that already works for a single problem and, later, the full product with its dashboard and more screens.

A good MVP isn't a poorly made version of the final product. It's a small, well-made version of its most important part.

When it makes sense to start with an MVP

Starting with an MVP makes the most sense in these cases:

Your idea is new and nobody has paid for it yet. Before building everything, you need to know if anyone uses it.
You're going to sell a digital product. An app, a subscription platform or an online service used by people outside your company.
Your budget is limited. You'd rather invest part of it, learn and decide what's next with data.
You want to show partners or investors something that works. A version people can use is more convincing than a slide deck.
Your business already works and you want to test a new line. For example, selling online a service you deliver in person today.

And when you don't need one: if what you want is to organize a process your business already knows, like inventory or orders, you're not validating an idea, you're fixing something you already know hurts. There, a system built for your operation makes more sense, and it's also built in phases.

How to decide what goes in the first version

This is the hardest part and the one that saves the most money. These questions help you cut:

Who is your first user? Just one. If your product has customers, suppliers and admins, start with the one who pays or the one who has the problem.
What's the main problem you solve for them? Write it in one sentence. If you need three, it isn't clear yet.
What's the shortest path to solving it? From the moment they arrive until they get what they came for. That complete journey is your MVP.
What can be done by hand for now? Approving accounts, sending an email or putting together a report can be done by a person while you validate.
Does it have to be an app, or is the web enough? A website that opens on a phone launches faster and skips the app stores. We explain it in when a mobile app makes sense.

Cutting is deciding: the essentials go into the first version and the rest is set aside for later, without deleting it.

Goes in the first version

Signing up and logging in.
The main action, end to end.
What you need to get paid, if you charge from the start.
A simple dashboard for you to manage the basics.
Measuring what people do inside.

Can wait

Several languages and color themes.
Elaborate notifications.
Advanced reports and exports.
Integrations with other systems.
«Nice to have» features nobody has asked for.

A useful rule: if a feature doesn't help you find out whether the idea works, it can wait for the second version.

What an MVP shouldn't cut

Cutting features is fine. Cutting what you can't see is not. This goes in from day one:

Account security. Properly stored passwords, account recovery and everyone seeing only their own data.
A foundation that can grow. If the MVP works, what comes next is built on top of it, not from scratch.
Your data and code in your name. The domain, the cloud, the repository and the app store accounts. We explain why in what GitHub is.
Measurement. Without usage data, the MVP teaches you nothing.
Privacy notice and terms. If you store people's data, you need them even if your product is small.

What you see is the app. Underneath are the database, the dashboard to manage it, the app store listing and the updates. An MVP cuts screens, not this part.

Be wary of a «quick» MVP where the code isn't in your name or that can't be handed to another provider. If the idea works you'll want to grow it, and that's exactly where it hurts.

Two real examples: how a first version gets cut

This is the exercise we do when a project starts, applied to two products from our portfolio. What they have today is real; the first version is how we would split them if they were starting from scratch.

Nichtarm: a personal finance app

Nichtarm is our own product: an app published on the App Store, with a web version that uses the same account. Today it has accounts and cards, budgets by category, savings goals, recurring charges, debts, shared plans that work out who owes whom and voice expense capture with artificial intelligence.

Nichtarm: an app to log your transactions and see where your money goes, without connecting your bank.

Its main question is «where does my money go?». An MVP that answers it only needs signing up, adding your accounts, logging transactions and seeing spending by category. Budgets, goals, shared plans and voice capture are features that get added once people already use the basics.

ALFRANET: an online course platform

ALFRANET is Alfra Group's platform for selling and managing its lean manufacturing courses. Today it has protected videos, subscription plans, company accounts with seats per course, exams, diplomas with a verifiable ID number, scholarships and invoicing.

ALFRANET: a student's home screen, with the content of their plan.

The course catalog, with search and a category filter.

Here the main question would be «do people buy these courses online?». An MVP only needs someone to pay, log in and watch the videos, plus a dashboard to upload courses. Company accounts, exams with diplomas, scholarships and automatic invoicing come once there are students.

How to know if your MVP works (and what's next)

Before launching, decide what would tell you it's going well. It's almost always one of these three things:

People complete the main action. Not just signing up: doing what they came for.
They come back. A product that gets used once and forgotten doesn't solve a real problem yet.
They pay or ask for it. If it's paid, someone pays; if it's free, they recommend it or ask for more.

Beyond the numbers, talk to your first users. A handful of in-depth conversations will tell you more than a dashboard full of charts.

Growing in phases: each version builds on the previous one, with the same account and the same data, instead of starting from scratch.

With that you decide the next step: keep going with the second version, adjust course with what you learned or stop before spending more. All three are good news, because an MVP exists precisely to reach that decision with data, not hunches.

What drives the price of an MVP

We won't give you a number here, because it depends on what goes into the first version. What we can tell you is what pushes it up or down:

How many types of users. Customers only is simpler than customers, suppliers and admins, each with their own screens.
How many complete flows. Each end-to-end journey (signing up, buying, booking, posting) is separate work.
Whether it takes payments. One-time charges, subscriptions or payments between users need more care.
Web or app stores. Publishing on the App Store and Google Play adds work and each store's review.
What it connects to. Invoicing, maps, WhatsApp or the system you already use.
Whether it uses artificial intelligence. It adds design and testing, and it's worth it when it's part of the main problem, not decoration.

In the quote tool, an MVP falls under «Shall we build something together?» and we set the timeline on the call. For reference, the same quote tool puts an app at 8 to 14 weeks and a web system at 6 to 12; the whole point of cutting is to land as low as possible.

Cutting well lowers the price more than any discount: every feature that waits for the second version is time and money you invest later, with data from your users.

Who to build your MVP with

There are several paths, and each one fits a different moment:

You, with no-code tools. Good for quickly validating a simple idea. It gets complicated when you need payments, per-user permissions or growth.
A freelancer. Works if the scope is clear and small. Everything depends on one person and their availability.
An agency or a studio. Design, development and launch with a process. In how to choose a software development agency we tell you what to check.
A technology partner. Besides building, they help you decide what to build, and sometimes work with equity or revenue-sharing arrangements.
A technical cofounder. Ideal if you find one, but finding them takes time and they keep part of your company.

Whoever it is, ask them to explain what stays out of the first version and why. Someone who says yes to everything isn't looking after your budget.

How we build your MVP at Vareliuu

As a technology partner, we build your product with you from the first call. This is how we work:

Demo Friday: every week you try what was built on your own computer, on a call with the team.

A 20-minute call. You tell us the idea, what it solves for whom and what you have today. If what you need isn't an MVP, we'll tell you.
We define the first version. Together we write down what goes in, what waits and how we'll measure whether it works.
A written quote. Scope, timeline and price in a clear document, within two or three days. If you're interested in an equity arrangement, we discuss it here.
Design you can test. Screens and flows you can show your users before any code is written.
Progress every Friday. We work in weekly sprints: every Friday you try what's new from your phone or your computer.
Launch and second version. Domain, app stores and analytics ready to go. Then we measure with you and decide what's next with data.

If you have an idea and you're missing the technical team, tell us what you want to build in the quote tool and we'll map out the first version together. On technology partner you'll see everything we do.

Preguntas frecuentes

What does MVP mean?

It stands for minimum viable product: the simplest version of a product that already solves the main problem and can be put in the hands of real customers to learn from them.

How much does it cost to build an MVP?

It depends on how many types of users it has, how many complete flows, whether it takes payments and whether it goes to the app stores. In our quote tool you pick «Shall we build something together?», tell us the idea and we send you scope, timeline and price in writing after a 20-minute call.

How long does it take to build an MVP?

It depends on what goes into the first version. For reference, our quote tool puts an app at 8 to 14 weeks and a web system at 6 to 12; a good cut aims for the low end of those ranges.

What's the difference between a prototype and an MVP?

A prototype is a set of screens that look real but don't store information; it's for testing whether the idea makes sense. An MVP already works: it has accounts, stores data and people can actually use it.

Do you have to throw the MVP away once it works?

If it was built well, no. The same foundation grows with the second version. That's why an MVP cuts features, but not security or the way data is stored.

Do you work for equity?

It's possible. Besides fixed-scope projects, we discuss equity or revenue-sharing arrangements depending on the idea and the moment.