Most failed projects do not fail because they were built badly. They fail because too much was built before anyone checked whether people would use it.

What an MVP is—and is not

An MVP is not a cheap, unfinished version of the real app. It is the smallest product that answers one question: will the target user change how they work because this tool exists?

That leads to a rule that settles most scope debates: if a feature does not change the answer to that question, it does not belong in version one. Settings, data exports, profile editing, and dark mode are things users ask for after they have started using the product.

How to cut scope

Sort the wish list into three groups:

  • The product does not work without this. Usually, this means two or three things. For a vehicle handover app, it is taking photos and generating a report. Everything else is an extra.
  • This can be done manually. Sending invoices, adding a client, or exporting data. With ten users, doing this manually takes minutes a week instead of a week of development.
  • This can wait. Anything that improves the experience but is not essential to using the product.

The most useful question in a scope meeting: what happens if we leave this out? If the answer is “it would be nicer,” move it to version two. If the answer is “the job cannot be done,” keep it.

Six weeks, one week at a time

  • Week 1 — agree on scope. Feature list, app flows, and rough screen sketches. By the end of the week, we know what we are building—and what we are not.
  • Week 2 — the foundation. Project setup, database, sign-in, and navigation. You can install the app and move through it, even though the features do not work yet.
  • Weeks 3 and 4 — the main flow. Build the one thing the product exists to do, end to end, using real data.
  • Week 5 — edge cases. No network, an interrupted action, missing data. This is where an MVP differs from a demo.
  • Week 6 — testing and release. Real devices, fixes, app store materials, and the first version in the hands of early users.

At a typical hourly rate, that is around 200–260 hours of work, or €5,000–€6,500 — in line with the lower end of the range in our article on mobile app costs, as intended.

What we deliberately leave out

To make six weeks realistic, some things have to be left out. Usually:

  • admin interface — use direct database access or an off-the-shelf tool instead;
  • in-app payments — invoice the first users manually;
  • multiple languages — start with the language your first users speak;
  • highly polished design — keep it consistent and clear, but skip original illustrations and animations;
  • advanced reports — there is nothing to report until you have data.

When an MVP is not a good idea

This approach has limits. Do not build an MVP if:

  • You are replacing a system people already use. Existing users will not accept a version that does less than the tool they already have.
  • You work in a regulated industry. Fiscalization, medical data, and similar areas do not have a version that is “compliant enough.”
  • Completeness is the only source of value. If the product only makes sense when it covers the entire process, half a process is not an MVP—it is an unusable tool.

After the first version

An MVP succeeds if you know more after six weeks—not because you have a finished product. Early users show which assumptions were wrong, and there is almost always at least one. Then you decide what to build next based on evidence instead of guesses. That is the whole point.