Everyone agrees a first release should be small. The disagreement starts at the second meeting, when it turns out that half the room means "fewer features" and the other half means "the same product, roughly finished".

Both readings produce failures, and they look different. The over-large MVP takes nine months and launches into an audience that has moved on. The over-small one launches in three weeks, nobody can complete anything with it, and the conclusion drawn is that the idea does not work — when what did not work was the version.

The test is a completed job, not a feature count

A useful first release lets one kind of user do one whole thing, from beginning to end, and get a real result. Not a demonstration of the thing: the thing.

If your product is for booking inspections, the MVP has to actually book an inspection, and the inspector has to actually see it. It does not need reporting, invoicing, multiple roles, notification preferences or a mobile app. It does need the booking to work well enough that a real customer would use it for a real inspection rather than as a favour.

That is the line. Above it you learn something true. Below it you learn only that people do not like using something incomplete, which you already knew.

What to cut without hesitation

  • Second and third user types. Build for the one whose problem is sharpest. Every additional role multiplies screens, permissions and testing.
  • Administration interfaces. For the first release, configuration can be done directly in the database by your own team. This is not a shortcut you keep, but it is many weeks of work deferred.
  • Edge cases. Handle the ninety per cent path and let the rest fail visibly and safely. You will discover which exceptions actually occur, which is better than guessing which to build.
  • Anything driven by scale. Optimisation, caching strategy, horizontal scaling. A hundred users do not need it and building for a scale you have not reached is the most reliable way never to reach it.
  • Integrations that are conveniences. Exporting to a spreadsheet is a fine substitute for a synchronised integration in version one.

What cutting these breaks

Some things look like scope and are actually foundations, and removing them costs more than it saves.

  • Authentication and access control. Retrofitting proper authorisation across a system built without it is a rewrite of every endpoint. Build it thinly, but build it.
  • The data model. Structure of data is the hardest thing to change later, because everything else refers to it. Spending an extra week here is almost always repaid.
  • Anything touching money or personal data. Payments, consent and deletion need to be right at launch. There is no version of these that is acceptable to get wrong in front of real users.
  • Basic instrumentation. If you cannot see what people did, the release does not answer the question it was built to answer.

Write down the question first

Before scoping, put in one sentence what this release is meant to find out. "Will facilities managers book through a web form instead of phoning?" is a question. "Validate the product" is not.

The sentence does the scoping for you. Anything that helps answer it is in; anything that does not is out, however reasonable it sounds. It also tells you in advance what result would count as a negative answer, which is the discipline that stops an MVP from being a nine-month build with a modest name.

Plan the fortnight after launch

The most common mistake is not the scope of the MVP but the assumption that the team disperses once it ships. Real users produce a burst of small, obvious, high-value changes in the first two weeks, and the value of an MVP is largely in acting on those quickly.

Keep the team available and the budget open for that period. A first release nobody can respond to is a survey with extra steps.

And be honest about what "viable" means for you

For an internal tool, viable can mean rough: the users are colleagues, they know it is version one, and a shared understanding covers a lot of gaps.

For a product a stranger pays for, viable includes trust — it has to look finished enough to be credible and work reliably enough not to lose data. That is a higher bar, and pretending otherwise produces the launch where the feedback is all about the sign-up form.