Skip to main content

MVP

Minimum Viable Product

Illustration of MVP

In short

An MVP is the smallest build that can test an open assumption in real use. Not a stripped-down version of the finished product, but the smallest thing that answers one question: does anyone use this, and will anyone pay for it? The «viable» is the part most often dropped – an MVP has to be usable, or it measures nothing at all.

The question comes before the scope

An MVP without a stated assumption is not an MVP, it is an unfinished product. So the first artefact is not a feature list but a sentence: «We believe X will happen, and we are wrong if Y.»

With that sentence in place the scope largely writes itself – anything that does not help test it drops out. Without it, scope becomes a negotiation, and negotiations are won by whoever misses a feature loudest.

What goes in, and what can wait

In goes the one path a real user actually walks, complete and usable. Almost everything else can wait: admin screens, role management, multiple languages, reporting, design variants.

One apparent exception that isn't one: security and data protection never wait. An MVP holding real personal data falls under data protection law from day one, even with ten test users.

How you know it worked

An MVP succeeded if it enables a decision – keep building, pivot, or stop. An MVP that leaves you exactly as informed as before has missed its purpose, however good it looks.

The unwelcome result is the more valuable one: «nobody uses it» after eight weeks costs a fraction of the same insight after two years.

The mistake that costs most

The MVP gets built, gets validated – and then quietly becomes the foundation. Code written to answer one question does not carry a product for five years.

Decide before you start what happens afterwards: throwaway MVP (fast, cheap, gets replaced) or foundation MVP (slower, dearer, grows with you). Either is a sound choice. Only making it in hindsight is expensive.

How we handle it

ALPENIQ Labs writes the assumption down before the first line of code and names which of the two routes the build takes. Anything that does not serve the test is not in the quote.

How we work: MVP development, web applications and mobile apps.

Where this sits with us

Last reviewed: 2026-09-14

A term in your quote that nobody explained?

In a strategy call we translate the offer in front of you – even when it did not come from us.

Back to the glossary

We use cookies to understand how this website is used and to improve it. Necessary cookies are always active; everything else only with your consent. More in our Privacy Policy