MVP development: how to decide what goes in the first release

Most first releases are too big. The team lists everything the product should do, ranks it loosely, and builds the top half. Months later it launches, and learns the one thing it needed to know at the start: whether anyone wants it.

A minimum viable product is the answer to that. The phrase was popularised by Eric Ries in The Lean Startup, and its point is easy to lose: an MVP is not a cheap, poor version of the finished product. It is the smallest release that can test your riskiest assumption with real users.

This is a scoping method you can run in an afternoon with a whiteboard, and it works whether you build the product yourself or hire a team.

Start with the assumption, not the feature list

Every product rests on a few beliefs that might be wrong. They come in three kinds:

• Desirability: do people want this enough to change what they do?
• Feasibility: can we build it, with the data, integrations and performance it needs?
• Viability: can it pay for itself?

Write the assumptions down and pick the one that would end the idea if it were false. That one decides what the MVP must contain. If the riskiest belief is "clinics will book online instead of phoning", you do not need reporting, roles or a mobile app to test it.

One user, one job

Pick a single kind of user and the single job they are trying to get done. Write the whole product as one sentence:

A [user] can [do this] and gets [this outcome] in [this time].

If the sentence needs an "and also", you are describing version two. Everything that does not serve that sentence is a candidate to cut.

The delete test

List every feature you have in mind. For each, ask:

If this were missing, could we still run the test?

If yes, it goes on the "later" list. Be strict; the delete test is uncomfortable on purpose. Then sort what is left:

• Must: the test cannot run without it.
• Should: it makes the test easier or safer, but you can survive without it.
• Later: everything else, including the ideas you love.

Only the "must" list is the MVP. The "should" items are the first candidates when there is room.

Do it by hand first

Before you automate something, ask whether a person can do it behind the scenes for the first users. A "concierge" version is one where you do the work manually. A "Wizard of Oz" version looks automatic to the user while a person does it out of sight. Either can answer would people use this? for a fraction of the cost of building it. What you learn also tells you which parts are worth automating.

Manual is a good answer for approvals, matching, reports, recommendations and anything with unclear rules.

Buy the commodity parts

Some parts are solved and rentable. Building them yourself spends the MVP budget on things that do not test your idea:

• Sign-in and identity. Use a proven service, and never write your own password storage.
• Payments. Use a payment provider. Do not touch card numbers.
• Email and notifications, file storage, search, maps.
• Admin screens. A spreadsheet or a simple back-office tool can serve early on.

Spend your building time on the part that is yours: the thing that is meant to be different.

Pick boring technology and one platform

An MVP needs to be changed quickly, so favour tools your team knows well, a simple architecture that one person can hold in their head, and one platform to start (the one your users are on). Adding platforms is easy to justify once people use the first one. For the mobile decision see Flutter, React Native or Capacitor.

What never to cut

A minimum product is not a careless one. Even the smallest release should keep:

• Security basics: proper authentication, encrypted connections, and least-privilege access to data. Your first users are trusting you with something.
• Backups and a way to restore. Losing early users' data ends the test.
• The measurements that answer your question. If you cannot see whether the assumption held, you built a demo, not an experiment. Decide which events to record before you write code.
• Accessibility fundamentals: real labels, keyboard operation and sufficient contrast are far cheaper to build in now than to retrofit (accessibility-aware development).
• Legal basics: a privacy policy and terms, and consent where the law requires it.

Decide what success looks like before you build

Write the target down while nothing is at stake, for example "of the people we invite, this many complete the core flow", with the number you would need in order to keep going. Deciding after you see the data invites wishful reading.

Then decide the three outcomes in advance: keep going, change direction, or stop. Stopping cheaply is a good outcome.

How this connects to cost and vendors

The smaller the scope, the smaller and more predictable the estimate. A scope built this way gives a vendor something concrete to price. See how to estimate what an app costs for the method, and how to choose a development partner for the questions to ask. Build in milestones, with a working demo at each one.

Frequently asked questions

What is the difference between an MVP, a prototype and a pilot? A prototype demonstrates an idea and may not work. An MVP is a working release used by real people to test an assumption. A pilot is a limited rollout of something you are already confident in.

How long should an MVP take? As short as the smallest test allows. If the plan runs long, the scope has probably outgrown the assumption. Cut again.

Can I test demand before building anything? Often, yes: interviews, a landing page describing the offer, or a manual service. They are cheaper than software, and they can answer the desirability question.

Should the MVP be built to scale? Build so that it can be changed and grown, not so that it already handles millions of users. Avoid choices that trap you, and postpone the rest until real use tells you what to scale.

When should I bring in a development team? When the scope fits on a page and you can say what the test will show. That is also when a team can give you a useful estimate.

Where to go from here

If you have an idea and a deadline, send us the sentence from the section above and the assumption behind it. We will reply with the questions we would ask before writing any code. Send requirements, or read about custom software development for startups.