How to build an MVP: choosing the one flow, leaving the rest out, and measuring what you learn

To build an MVP, you pick one core flow that solves one problem for one defined group of users, build it so it works end to end with a basic admin screen for your team, launch it to real people, and measure what they do. For a focused web app that usually takes roughly 6 to 12 weeks from the start of discovery to launch; everything else waits on an after-launch list.

Eric Ries, who popularised the term, defined the minimum viable product as the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort. The important word is learning, not minimum. Our guide to developing an app for your business covers every stage of the process; this article is about its hardest decision: what goes into the first version and what does not.

What an MVP is, and what it is not

An MVP is not a bad product shipped fast, nor a demo that looks good in a pitch and does not work. It is a narrow product: it does little, but does that little all the way through, so a real person can use it without someone from the team holding their hand.

For an existing business, the MVP is rarely a startup; it is a new channel: an appointment booking app, a client area, online ordering. The rule is the same: prove that customers use one action before building everything around it.

How to choose the core flow

Answer four questions, in writing:

1. Who is the first user? Not “everyone”, but one group you can reach in the first week.
2. Which one problem do they solve awkwardly today? A phone call, WhatsApp, a spreadsheet, a receptionist’s diary.
3. What action gives the product its reason to exist? Booking, ordering, requesting a quote.
4. What will prove it works? A number you can measure after a few weeks, set before building starts.

Whatever that action needs to work goes in: sign-in, payment if there is one, a notification, a screen for staff. Everything else moves to a separate list in order of priority. The Névé product design case shows this stage in practice: the research, flows and wireframes of an app for a fictional clinic, and what changed after testing with users.

What to leave out of an MVP

This list comes back in almost every project. Any item on it may matter, but not before the core flow has proved itself:

• Loyalty programmes, points and rewards.
• In-app chat (WhatsApp or email is enough at first).
• Several languages, if most first users speak one.
• Advanced reporting. An export to a spreadsheet and basic analytics will do.
• A native app in the stores, if a web app does the job.
• Settings, personalisation and dark mode.
• Automating things that happen once a week. Do them by hand until they prove to be recurring.

No-code, low-code or code?

Before writing a line of code, ask whether you can learn the same thing without it. Three routes, cheapest first:

No product at all

A landing page that describes the service and measures sign-ups, or a service done by hand behind a simple form. It answers whether there is demand before you invest in development. How to build a page that actually measures is in how to build a landing page that converts.

No-code and low-code tools

App builders, form tools and automation platforms let you assemble a working flow in days. They suit testing an idea and small internal tools. The limits show as the product grows: design that is hard to fit to the brand, complex permissions, subscription costs that rise with users, and data held by an outside vendor. Know in advance how you would leave the tool if the experiment succeeds.

Code

When the MVP is a channel customers will use for a long time, when it has to look like the brand, or when it connects to payments, a calendar and a CRM, code is the better fit. A web app, or a Telegram mini app, built in JavaScript and launched inside Telegram, lets you launch without store review. When you do need the stores is covered in native app vs web app.

How long does it take to build an MVP?

These ranges come from projects for small and mid-sized businesses that we see, and depend mostly on the number of integrations and how quickly decisions are made on your side:

What it costs depends on the same variables; we lay out ranges in app development cost.

Decide in advance the number that counts as success and the one that would make you change direction; otherwise every result looks like a promising start.

What to measure after launch

Downloads and sign-ups are pleasant numbers that say little. What teaches you is what happens next:

• Completion: how many who start the core flow finish it, and where they drop off.
• Return: how many come back to do it again, after a week and after a month.
• Substitution: how many actions moved from the phone or WhatsApp into the product.
• Questions: what users ask your staff. Every repeated question is an unclear screen.
• Requests: what people ask for again and again. That is the next version’s list, not the ideas from the first meeting.

Decide in advance the number that counts as success and the one that would make you change direction; otherwise every result looks like a promising start. Once there is enough traffic, A/B tests help decide between two versions of the same screen.

From MVP to version one

If the MVP proves itself, the next step is not to add the whole list but to strengthen what works: fix where people drop off, add what users asked for repeatedly, and build what staff need to run the product at larger scale. This is usually when the admin system grows too; what belongs in one is in our guide to custom admin dashboards.

For that step to be cheap, plan it in the MVP: a back end with a clean API, permissions that do not depend on the screen, and a design system with defined components so no new screen starts from zero. The SKYLARK design system is an example of that base, and the SKYLARK platform itself, for booking private flights, is built so client and operator work on the same back end. Both are concepts we built; the company is fictional.

Common MVP mistakes

• Scope creep: every meeting adds “just one small thing”, and launch slips month after month.
• No success measure: three months later nobody can say whether it worked.
• Too minimal: a broken or ugly product nobody keeps using, leading to the wrong conclusion that there is no demand.
• No staff side: customers book, and the team copies everything into a spreadsheet by hand.
• Building for everyone: with no defined first user, there is nobody to ask and nobody to learn from.
• Throwaway code: an MVP built with no thought for what comes next, so version one starts from scratch.

MVP scope worksheet

Fill in the table before approaching a vendor. It also works as an attachment to your brief:

What Libra builds here

At Libra we build first versions as web apps and Telegram mini apps, with an admin system for the team and in the brand’s design, on a base you can keep building on. The details are on our apps and business systems page.

If you have an idea and a long list, send a brief with the first user and the core action. We reply by email with a proposal for what goes into version one, a written price and a date.

Questions

What is an MVP?

A minimum viable product is the smallest version of a product that lets you learn something real from real users: one core flow working end to end, with measurement of what happens. It is narrow, not sloppy.

How long does it take to build an MVP?

A focused web app usually takes roughly 6 to 12 weeks from the start of discovery to launch. An MVP with several user types and payments can take 3 to 5 months.

What is the difference between an MVP and a prototype?

A prototype is clickable screens for testing the flow, with no real system behind them. An MVP is a working product that real users use.

Can I build an MVP with no-code tools?

Yes, and sometimes that is the right way to test an idea or build a small internal tool. Know the tool’s limits in advance and how you would move to code if the experiment succeeds.

What should not be in an MVP?

Anything the core flow does not need to work: loyalty programmes, chat, advanced reports, several languages, and store apps if the web will do. Security, privacy and error handling stay in.

What should I measure after launching an MVP?

How many complete the core flow, how many return to it, how many actions moved from the phone into the product, and what users ask and request. Set the success measure before launch.

Getting started

Want this for your business?

Send a short brief: three required questions, the rest only if you like. We reply by email with a direction, a written price and a date.

Send a brief→The service: Apps & business systems→