What an MVP should include — and what to leave out

Start from the riskiest assumption

Every new product rests on a few assumptions: that people have this problem, that they will use your product to solve it, and that they will pay for it. Pick the one that would sink the product if it turned out to be wrong. The MVP exists to test that one, as cheaply and quickly as it honestly can.

What to include

• One end-to-end journey, from arriving to getting the core value, with no dead ends.
• The trust basics that journey needs: secure sign-in, data protection, and payments if you are testing willingness to pay.
• Enough design quality that people judge the idea, not the rough edges.
• Measurement on the key steps, and an easy way for users to tell you what is missing.
• A simple admin view, so your team can support early users without a developer.

What to leave out

• Multiple user roles and permission levels.
• Settings and customisation nobody has asked for yet.
• Integrations you can handle by hand for the first users.
• Automation of tasks that are cheap to do manually at low volume.
• Infrastructure for scale you do not have — build for hundreds of users, not millions.
• Every platform at once: pick web or mobile first.

Manual first, automate later

Many good MVPs quietly run some steps by hand: a person approves sign-ups, sends the report or matches the order. Users still get the outcome, and you learn which steps genuinely need automating before you pay to build them.

An MVP is not a prototype

A prototype shows how something might work, so you can get feedback on it. An MVP is a real, working product released to real users, so it has to be reliable and secure for that first audience. "Minimum" applies to the scope, not to the quality.

How long it should take

For most products, a focused MVP takes roughly six to twelve weeks from an agreed scope to launch. If the plan says six months, the scope almost certainly still contains things to cut. A short scoping exercise before the build is the best way to find them.

Decide in advance what success looks like

Before launch, write down the signal that would make you continue, change direction or stop — for example, the share of new users who complete the core journey, or how many come back the following week. Without a line drawn in advance, every result looks encouraging.

If you want help shaping and building one, see MVP development, or pay for a defined build monthly.