MVP or full build? How to decide what to launch first

Many new products have the same problem. They are not too small when they launch. They are too big. The team spends months building features that nobody asked for. Then real users arrive and want something a little different.

So the real question is not "MVP or full build?". It is: what is the biggest risk, and what is the cheapest way to remove it?

Two kinds of risk

Every product has two kinds of risk.

• Will people want it? Will they use it, and will they pay for it? Most new products have this risk.
• Can we build it and run it well? Will it work with other systems, and will it be reliable? Internal systems and big replacements often have this risk.

If your big unknown is "will people want it?", building everything first is a mistake. You spend the whole budget before you find out. If your big unknown is "can we build it?", a very small test can give you false confidence.

When a small first version (MVP) is right

Start with an MVP when:

• You are selling to people you have not served before
• Your price or main feature has not been tested with paying customers
• You need proof to raise money or to get approval inside your company
• The full idea would take many months to build

An MVP is not "a smaller copy of everything". It is the smallest product that tests your riskiest idea with real users. One feature that works well is better than five that half work.

When a bigger first version is right

Build more at the start when:

• People already use an old system and will only move when the new one does everything
• Security, legal rules or moving data cannot be done halfway
• The product replaces a system inside your business

Even then, build in steps. Run the new system next to the old one. Switch over only when the new one works.

Three questions for your first version

Ask these questions and write down the answers:

1. What must a user be able to do on day one for the product to be useful at all?
2. What will we learn from watching people use it?
3. What can we do by hand for now? Many early products have a person doing one step manually until there are enough users to automate it.

If a feature does not help with one of these, it can wait for the next version.

Built small, but built properly

A small product should still be a real product. It needs secure log-ins, real data, simple analytics (so you can see what people do) and code you can keep. This is what we call a production-ready MVP. When it works, you grow it instead of starting again.

What to do next

If you have a tested idea, MVP45 takes it live in 45 days for a fixed price. If you need a bigger first version, our MVP development and bespoke software work is planned in short steps, and you see working software every week.