MVP app: how to build the first version of your product without burning the budget

1. What is an MVP?

An MVP (Minimum Viable Product) is the smallest version of a product that solves one specific problem well enough that real users want to use it. Not a prototype to show investors and not a Figma mockup, but a working app — cut down to the core.

The goal of an MVP is not to impress. The goal is to learn: whether people come back, whether they pay, what they are missing. Any feature that does not help answer that can wait.

2. How to choose the features for the first version

Start with one sentence: “[who] uses the app to [do what], because today [what problem they have]”. Everything that does not serve that sentence goes on the “later” list.

A practical exercise: write down every feature that comes to mind and split them into three groups:

• —It does not work without it: the user's main path — in a booking app, say: picking a slot, confirmation, a reminder.
• —Nice to have, but you can manage without: filters, PDF export, dark mode, signing in with five different services.
• —Someday: an analytics dashboard, a loyalty programme, integrations with systems someone might use one day.

Only the first group goes into the MVP. The second waits until users ask for it themselves.

3. What to leave out of an MVP

Most of a first version's budget is eaten by things that look good on a requirements list but test nothing:

• —an elaborate admin panel — early on, data can often be handled directly in the database or a spreadsheet,
• —a custom payment system, when an off-the-shelf gateway or even a manually sent invoice will do,
• —separate iOS and Android apps from day one, before you know whether the product will catch on at all,
• —scaling for a million users, when the first goal is the first fifty.

Handling part of the process by hand at the start is not embarrassing; it is economical. You automate what you already know works.

4. Which technology to start with

For most MVPs the best choice is a web app or a PWA — it runs in the browser on any device, can be installed on a phone's home screen, and fixes reach everyone instantly without waiting for an app store.

When the app needs deep integration with the phone (background work, Bluetooth, advanced notifications), a sensible compromise is one codebase wrapped as an Android and iOS app — with Capacitor, for example. A fully native app makes sense when performance or hardware access is the heart of the product.

On the server side, ready-made platforms such as Firebase or Supabase provide sign-in, a database and file storage without building it all from scratch. At the MVP stage that usually saves weeks.

5. How long does it take to build an MVP?

A well-scoped MVP is usually a few weeks of work, not a few months. If the plan for the first version runs to half a year, it almost always means too much has gone into it.

A sensible timeline looks like this:

1. 1.A workshop and a written scope: one main user path, a “later” list.
2. 2.Screen designs and a clickable mockup — changes are cheapest at this stage.
3. 3.Building in short stages with a live preview, so you see progress every few days.
4. 4.Testing with a handful of real users before the official launch.
5. 5.Launch, measurement and a first round of fixes based on the data.

I cover the wider cost ranges in a separate article on how much a mobile app costs.

6. How do you know the MVP worked?

Before you start building, write down what success looks like. Without that, any result can be read as “not bad”. The most common measures are:

• —Retention: how many users come back after a week and after a month. Downloads say little; return visits say whether the app solves the problem.
• —The main action: how many people finish the key path — a booking, an order, adding their first entry.
• —Willingness to pay: even a token fee or a sign-up for a paid tier says more than ten surveys.
• —User requests: what they ask for most often. That is a ready-made priority list for version two.

7. Common questions about MVPs

Will the MVP have to be rewritten from scratch later?

Not if it was built properly — a narrow scope does not mean sloppy code. A well-written MVP grows feature by feature. A rewrite usually threatens those who built the first version as a shortcut in a no-code builder with no access to the code.

Can I start with a website instead of an app?

Yes, and it is often worth it. A landing page describing the product with a waiting-list sign-up tests interest before you write the first line of the app.

Can an MVP go on Google Play and the App Store?

It can, but allow time for store review — a first submission can come back with comments. A PWA lets you launch without that step and add the stores once the product proves itself.

8. Build an MVP that teaches you something

I build web apps, PWAs and Android apps — including my own products, from idea to working version. I will help you narrow the scope to what really needs testing and pick technology that will not block later growth.

Describe your idea in a few sentences and you'll get a free MVP quote within 48 hours.