Minimum and viable pull against each other, and most MVPs fail at whichever word the team was less interested in. Engineering-led teams build something minimal that nobody can use. Business-led teams build something viable that took a year and was never minimum.
The useful definition is narrower than either: an MVP is the smallest thing that will teach you whether the idea works. Not the smallest product. The smallest experiment that produces a trustworthy answer.
Start From the Riskiest Assumption
Every product idea rests on a stack of assumptions. That a particular group of people has this problem. That they would change how they work to solve it. That they would pay. That you can deliver it at a cost that leaves a margin.
Write them down and rank them by what happens if you are wrong. One of them is load-bearing: if it fails, the rest does not matter. That assumption is what the MVP exists to test.
This usually reorders the backlog dramatically. If the risky assumption is that people will pay, the MVP needs payment and can skip the admin panel. If the risk is technical, whether the model is accurate enough or the integration is fast enough, then the MVP might have almost no interface at all.
What to Cut
Cut anything that serves a user you are not testing with. Second personas, admin tooling for a support team that does not exist yet, reporting for a management layer that has nothing to report on.
Cut scale. Building for a hundred thousand users when you have none is the most common and most expensive form of premature optimisation. Build for the number you can realistically reach in six months, and make sure you can see when you approach it.
Cut configurability. Every setting is a branch to build, test and support. Pick a sensible default and change it later when a real user complains.
Cut the edge cases, but write them down. The point is not that they do not matter; it is that they should not delay the answer to the question you are asking.
Replace rather than build, wherever the thing is not your differentiator. A spreadsheet, a manual process behind the scenes, an off-the-shelf tool. If a human doing it by hand can validate the idea, do that first.
What People Wrongly Cut
Authentication and the data model. These two are structural. Retrofitting real accounts, or reshaping the core entities once there is live data, is not a tidy-up, it is a rebuild. Keep them simple, but get them right.
Instrumentation. An MVP that does not tell you what people did is not an experiment, it is a launch. You need to know who signed up, where they stopped, and what they never touched. This is a small amount of work that determines whether the whole exercise produces an answer.
The ability to talk to users. A way to contact people who sign up is worth more than most features. The qualitative answer to why they stopped is usually not in the analytics.
Basic security and data protection. Shortcuts here are not deferred cost, they are liability. If you are handling personal data, the obligations apply to a prototype with fifty users exactly as they apply to a product with fifty thousand.
Enough quality to change it. The MVP is the thing you will iterate on. If it is built so carelessly that the second version means starting again, the speed was borrowed, not saved.
Decide What Success Means Before You Build
Write down, in advance, the result that would make you continue and the result that would make you stop. Both numbers. Do it before launch, because afterwards every outcome can be narrated as encouraging.
Pick a measure that reflects value received rather than interest shown. Sign-ups measure your marketing. Repeat use measures your product.
Agree how long you will wait and how many users constitute an answer. Small numbers are noisy, and a fortnight is rarely long enough to see whether anyone comes back.
What Happens Afterwards
Three outcomes are possible, and two of them are good. It works, and you invest. It clearly does not, and you have learned that cheaply, which is the entire point. Or the result is ambiguous.
Ambiguity is the dangerous one, because the temptation is to keep building in the hope that more product will produce clarity. Usually it means the experiment was not sharp enough. Better to run a second, tighter test than to fund a year on a maybe.
If it works, budget for the things the MVP deliberately skipped before adding features. The deferred items are a known debt with a known due date, and the cheapest moment to pay them is immediately after validation, not two years into growth.
Working out what to build first?
Tell us what you are trying to do and we will tell you honestly whether we are the right people for it.
Get in touch