Most founders know the advice: build a minimum viable product, launch early, learn from users. Fewer know what to do with it. Some build so little that the product cannot be judged fairly. Others build for a year, call the result an MVP, and launch with no clear idea of what they are trying to learn.
An MVP is not a small product. It is an experiment with a product attached. This article explains how to decide what goes into a first version, how to build it so it can grow, and how to make sure it teaches you something useful.
Start with the riskiest assumption
Every new product rests on assumptions. Write them down, then ask which one, if wrong, would end the business. Typical candidates:
- The problem: do enough people have this problem badly enough to change what they do?
- The solution: does our approach actually solve it better than what they use now?
- Willingness to pay: will they pay, and how much, and who decides?
- Reach: can we find and win these customers at a sensible cost?
- Operations: can we deliver the service reliably, for example with enough suppliers, drivers or tutors?
Your first version should be designed to test the riskiest one. Everything else is secondary.
You may not need software yet
Some assumptions can be tested faster without building anything:
- A landing page describing the product, with a way to register interest or pre-order.
- A service delivered manually behind a simple form, where the team does by hand what the software will eventually do.
- Conversations with potential customers about how they solve the problem today and what it costs them.
- A clickable prototype shown to users, to test whether they understand and want the workflow.
A tutoring marketplace, for example, might match students and tutors by hand for a few weeks using a form and a spreadsheet. If families keep coming back and paying, that is evidence worth more than any feature list. If they do not, the team has saved months of development.
The purpose of a first version is not to impress. It is to find out, as cheaply as possible, whether you are wrong.
Deciding what goes into version one
When it is time to build, use a simple test for every proposed feature: is it needed to complete the core journey, or to measure whether the core journey works? If not, it waits.
Usually in
- The one journey that delivers the main value, from start to finish.
- Sign-up and login, kept as simple as possible.
- Payment, if willingness to pay is one of your key assumptions.
- Basic administration so your team can support users and fix mistakes.
- Measurement of the steps in the core journey.
Usually out, for now
- Multiple user roles beyond what the core journey requires.
- Detailed settings and customisation.
- Native apps on every platform, when a responsive web app or one platform would do.
- Automation of tasks your team can still do by hand at current volumes.
- Integrations that can be replaced, for now, by a manual export.
Minimum, but not careless
Building less is not a licence to build badly. Some foundations are much cheaper to get right at the start than to fix later:
- Security basics: proper password handling, secure connections and access control. A data leak in the first months can end a startup.
- A sensible data model: spend time understanding the core entities, such as users, orders, bookings or listings, and their relationships.
- Mainstream technology: choose well-supported frameworks and hosting so you can hire and grow without a rewrite.
- Ownership: your company should own the code, the domain, the cloud accounts and the data from day one.
- Backups and logs: so you can recover from mistakes and understand what users did.
The aim is a product that is small in scope but solid in structure, so that the parts you keep can grow and the parts you discard can be removed cleanly.
Decide what you will measure before launch
Write down, before launch, what result would encourage you and what result would make you change direction. For example:
- Of the users who sign up, how many complete the core journey once?
- How many come back and use it again within a month?
- How many pay, and how many continue paying?
- What do users say when asked what they would miss if the product disappeared?
Agreeing these thresholds in advance protects you from the natural tendency to read any result as encouraging.
Time-box the build
Set a fixed period for the first version, commonly measured in weeks rather than months, and adjust the scope to fit it. Hold short, regular demos. When something takes longer than expected, cut scope rather than extend the date. A late MVP delays the learning it exists to produce.
After launch: learn, then decide
- Watch real usage. Look at where users drop out of the core journey.
- Talk to users. Especially those who tried once and did not return.
- Make one of three decisions: continue and improve, change a key assumption, or stop.
- Only then plan version two, guided by what you learned rather than by the original feature list.
Warning signs
- Nobody can state the main assumption the MVP is testing.
- The feature list keeps growing and the launch date keeps moving.
- There is no plan to measure whether the core journey works.
- The founders do not have full access to their own code and accounts.
Where RAED fits
We help founders scope and build first versions around a clear learning goal, with solid foundations and full ownership from the start. Sometimes our advice is to test with a prototype or a manual service before writing much code.
