What does an MVP need to be viable?

The one rule everything else follows from

A user must be able to start the task, finish it, and get the result they came for, without hitting a place where the product stops. Dead ends are what separate a small product from an unfinished one, and they poison the result: a person who abandons the task because the next screen doesn't exist tells you nothing about whether they wanted the thing.

This is why cutting scope means cutting whole paths, not cutting the ends off the path you kept. Serve one user type, one workflow, all the way through. Everything outside that line is negotiable, and most of it should be negotiated away.

What has to be in it, and why

Real data, stored properly. The first release is where a bad data model gets locked in, and it is the one decision that's genuinely expensive to reverse later — everything built afterwards assumes it. Spend the extra day here. Back it up from day one, because losing a user's work once ends the experiment.

Access control, if the data is personal. Not a permissions matrix — a login, and the guarantee that one user cannot read another's records. A URL that returns someone else's data because nobody checked ownership is the most common serious flaw in small first releases, and it is a breach whatever stage you call the product.

Failures you can see. Errors have to reach you without a user reporting them. At this size that is a log you actually read and an alert when something throws — not a monitoring stack. The point is that during the weeks when you are learning most, silence means working, not broken.

Measurement tied to the hypothesis. Decide the question before the build and make sure the release can answer it: how many people started the task, how many finished, where the rest stopped. Without that you get anecdotes, and the next decision gets made on whoever spoke last.

It works on the device people will use. Usually a phone, often on a poor connection. A first release that is unusable on the screen your users have produces a result about your layout, not your idea.

The legal floor. A privacy notice, a lawful basis for holding personal data, deletion on request, and a clear answer about where the data lives. Small does not exempt you, and retrofitting this is worse than building it.

What you can safely cut

Anything you can do by hand at the volume you actually have. Onboarding people yourself, running the weekly report manually, fixing a record straight in the database, sending an invoice from your own accounting software — all of it is cheaper than building the feature, and all of it teaches you what the feature should do when you finally build it. Manual work at ten users is not debt; it is research.

Also cut: the second user role, settings that could be a constant, notification preferences, search before there is anything to search, and every integration the workflow can complete without. The discipline is to notice the difference between the thing being necessary and the thing feeling incomplete without it. The second one is not a requirement.

How to tell it's ready to ship

Three checks. A person outside the project can complete the workflow without being talked through it. Nothing on that path can lose data or fail silently. And you can state what result would make you build more, and what result would make you stop. If all three hold, it is ready; if the only thing missing is features you would like to have, it was ready a week ago.

The temptation at this point is one more release before real users see it. That instinct is the thing an MVP exists to overrule — every extra week is spent building on an assumption you could have tested instead. For the framing behind all of this, see what an MVP actually is; for what a first build tends to cost, see custom web app pricing.

What happens after it works

The deferred list comes back, in the order your users prove it matters. That is the payoff of building small: the roadmap is written by evidence instead of by a kickoff meeting, and the features that get built are the ones people asked for twice. A focused first build typically lands in six to ten weeks, which means the answer arrives while the assumption is still worth testing.

What should not come back is the shortcuts. Manual steps that made sense at ten users become the bottleneck at a hundred, and the moment to automate them is when the volume says so — not before, and not three months after everyone started complaining. That transition is most of what ongoing app work actually consists of.

Questions