Building an MVP: from idea to first version

What an MVP is

MVP (minimum viable product)

The smallest version of a product that real users can use to solve one problem, and from which you can learn whether the product is needed. “Minimum” refers to scope; “viable” means that what is there actually works.

The term was popularised by the Lean Startup method. At its core is the build–measure–learn loop: first you name the problem, then you build an MVP so learning starts as early as possible, and decisions are made on measurement rather than gut feeling.

An MVP is not a prototype you show an investor, nor a “cheap version” you will rewrite later. It is a working product with very clear boundaries. If a user can't solve their problem with it from start to finish, it isn't an MVP yet.

Why start with an MVP

In the same analysis the most common reason is “ran out of capital” (70%), but CB Insights stresses that this is almost always the final cause, not the root problem. The money runs out because it is spent on a product the market hasn't confirmed.

This isn't just for startups. A company building a new service for customers or an internal system for its team runs the same risk: spending the budget on features nobody uses. We look at what that risk means in larger projects in how much a custom web system costs.

Not every MVP needs code

What matters is what you want to find out. If the question is “does anyone want this?”, a page with a description and a sign-up may be enough. If the question is “will people use it every day?”, you need a working product.

To test demand, a landing page is often enough: our landing page starts from €990 (up to 5 sections, a contact form, analytics) and takes 1–3 weeks. Once demand is confirmed, the working version is built.

1. Name the problem and the user

One sentence: who has the problem, what it is and how they solve it today. “The owner of a small construction firm collects staff hours from text messages by hand every evening” is a good starting point. “A platform for the construction sector” is not.

Before writing the first line of code, talk to a few people who have the problem. Don't ask “would you use an app like this?” – almost everyone says yes – but “how did you do this last week?” and “how long did it take?”. Answers about what has already happened are far more reliable than promises about the future.

2. Decide what success will mean

Before building, write down what you will measure and what result means “carry on”. For example: how many trial users complete the core scenario, how many come back after a week, how many agree to pay. Without that decision, any result after launch is easy to explain away as a success.

3. Choose what goes into the first version

Put every feature on a list and ask of each one: can the user solve the problem from start to finish without it? If they can, the feature waits for the next stage. What usually remains in the first version is sign-in, one core scenario and whatever is needed to use it safely.

4. Build it so you can keep building

“Fast and cheap” shouldn't mean “throw away after the test”. If the MVP works, you will build the next stages on top of it, so the data structure, sign-in and security have to be solid from the start. Save on scope, not on quality.

We most often use Next.js and Payload CMS, and choose the infrastructure to fit the product – usually containerised infrastructure, Cloudflare and European cloud providers. You approve the layouts before development, and you can click through and test an interim version during the build.

5–6. Launch, measure and decide

Launch first to a small group of real users you can talk to. Watch where they stop and ask why. Then go back to the success criterion you wrote down in step two.

• The result meets the criterion – you plan the next stage, usually the features you postponed in step three.
• Users use it, but not the way you expected – you change direction based on what they actually do.
• Nobody uses it or shows interest – you stop, having spent part of the budget rather than all of it.

Once the product starts growing, some of the manual work around it is often cheaper to automate than to build into the product – more on that in business process automation.