01 / What it is for
An MVP answers one question, not several
The point is not a small product. It is the smallest thing that tells you whether the idea works. Before writing a line, finish this sentence: we will know we were right if…
If you cannot finish it, you are not building an MVP. You are building version one and calling it something else to justify the corners.
02 / Include
The one path, done properly
The single journey that proves the point. One user, one job, start to finish. Not three half-journeys.
Whatever makes it real. If the idea is that people will pay, it must take money. A survey asking whether people would pay tells you almost nothing.
Enough polish to be judged fairly. People do not separate “rough” from “bad”. If it looks broken, your test measures the interface rather than the idea.
A way to see what happened. Basic analytics and a way to talk to the people who used it. An MVP with no observation is just a launch.
03 / Leave out
The things that always creep in
Admin panels. You can edit the database, or we can. Building an admin interface for a product with eleven users is weeks spent on the wrong thing.
Roles and permissions. Unless the question is specifically about teams, everyone is the same kind of user.
Settings. Every preference is a decision you are avoiding. Pick the default and see if anyone complains.
Scale. Do not build for a hundred thousand users you do not have. The architecture that survives success is a good problem for later.
Every integration. Pick the one your first customers already use. The rest is a wish list.
The second idea. The one that arrives in week three and is genuinely good. Write it down. Do not build it.
04 / The grey area
Three things people cut that they should not
Sign-in that works. Password reset included. Nothing destroys a test faster than people locked out on day two.
Not losing data. Backups exist from the first day there is anything worth keeping.
The legal minimum. A privacy policy and lawful handling of personal data are not phase two, and the rules do not care how small you are.
05 / How long
If it is longer than about three months, the question is too big
A six-month MVP is a contradiction. By the time it ships, the market has moved and so has your opinion, and you will have spent the budget that was supposed to fund the response.
When the scope will not fit, the fix is a narrower question, not a longer timeline. “Will restaurants pay for this” becomes “will these four restaurants use it for a month”.
06 / Honestly
Most MVPs fail because nobody decided what would count as failure
Agree the number before you launch. Not a vague sense of traction: an actual threshold, written down, with a date. Without it, any result can be read as encouraging, and that is how projects run for two years without ever being tested.
Tell us the question you are trying to answer and we will tell you the smallest thing that answers it.