What is an MVP, and how small should your first version be?
An MVP is not an unfinished product. It is a version that does one job properly and deliberately postpones the rest.
letworktechApril 8, 20262 min read
The MVP acronym damages more projects than it saves, because in practice it is treated as "an unfinished product". The difference matters: a good MVP does less, and does it properly. A bad one does everything halfway.
The real question: which assumption are you testing?
Every product idea rests on an assumption. "People would rather order from their phone than queue" is one. The only job of an MVP is to test that assumption as cheaply as possible.
Three honest ways to cut scope
- Cut the audience. Start with one branch, one team or one city instead of everyone.
- Postpone automation. Running the back office by hand is legitimate early on — it also teaches you the real workflow.
- Delay the admin panel. It is the most expensive, least visible part of a product.
Three things you should never cut
- The data model. A wrong structure doubles the cost of every later feature.
- Security. Authorisation is not a layer you sprinkle on afterwards.
- First impression. Users judge in thirty seconds. Fewer features is fine; sloppy is not.
How long should it take?
In our experience a healthy MVP ships in 6 to 10 weeks. Faster usually means the scope was never thought through; slower means you are building the full product, not an MVP.
The test of a good first version: is it still being used two weeks after launch?
ÜrünGirişim
Building something like this?
Let us scope it together.