A minimum viable product, or MVP, is the smallest version of a product that lets you learn whether people actually want it. The idea is simple. In practice, many MVPs end up either too small to teach you anything or so large that they take months and most of the budget.

Here is how we approach planning an MVP with clients, so the first release answers real questions instead of just shipping features.

Start with the question, not the feature list

Before deciding what to build, write down what you need to learn. For example: “Will small clinics pay to let patients book appointments online?” or “Will our sales team use a shared dashboard instead of spreadsheets?”

Every feature in the MVP should help answer that question. If a feature doesn’t, it can wait.

Define who it’s for, narrowly

An MVP for “everyone” is hard to build and harder to learn from. Pick one type of user and one situation. You can widen the audience once you know the core idea works.

A useful test: can you name five real people or businesses who fit your target user and would try the product this month? If not, the audience is probably still too vague.

Map the one journey that matters

Most products have a single journey that delivers their value. For a booking product, it might be “find an available slot and book it”. For an internal tool, “see today’s numbers in one place”.

Design and build that journey properly, end to end. Everything around it, such as settings, advanced filters or admin screens, can start simple or even manual behind the scenes.

Fake what you can, build what you must

Not every part of an MVP needs to be automated. Early on, it is often fine for a team member to handle a step manually, like approving an account or sending a report, while the product looks complete to the user. If the idea works, you automate those steps next. If it doesn’t, you haven’t spent money building them.

Build it so it can grow

“Minimum” should not mean “throwaway”. If the MVP succeeds, you will want to keep building on it. That means sensible architecture, clean code and the basics of security from day one, even if the feature set is small. Rebuilding everything after a successful launch is expensive and slows you down exactly when you have momentum.

Decide how you’ll measure success before launch

Agree on a few signals that will tell you whether the idea is working, for example how many invited users complete the main journey, how many come back, or how many agree to pay. Set these up before launch, so you are not guessing afterwards.

Prototype first

A clickable prototype lets you test the journey with real users before any code is written. It is much cheaper to change a design than a finished product, and users often reveal problems you would never have predicted. In our projects, we refine the design with 2–3 rounds of revisions before development starts.

Plan the next step, not just the launch

An MVP is the start of a conversation with your users. Before launch, decide roughly what you will do if the results are good, mixed or poor. That keeps the team focused on learning rather than defending the first version.

A simple checklist

  • We know the main question the MVP must answer.
  • We know exactly who the first users are.
  • The main journey is designed and tested as a prototype.
  • Non-essential steps are manual for now.
  • The foundation can grow if the idea works.
  • Success signals are defined and tracked from day one.

Planning an MVP? See how we help or tell us about your idea.