Why your MVP should be smaller

A familiar pattern: the first version starts small and quietly becomes a version one. A login is added because users expect it. A dashboard follows, because the login has to lead somewhere. Then settings, notifications and an admin panel. Months later there is a product nobody has paid for, resting on assumptions nobody has tested.

This is rarely a discipline problem. It happens because nobody agreed what the MVP was supposed to find out. Without a defined question, every feature sounds reasonable, and the cost of each one is paid in time you could have spent learning from customers.

Treat the MVP as an experiment

The word "viable" causes most of the trouble, because it suggests the product must be good enough to survive alone. A more useful definition: the smallest thing you can put in front of real people that tells you whether your riskiest assumption is true.

The riskiest assumption differs by idea, and each one calls for a different test:

• Demand: does anyone want this enough to change what they do today?
• Willingness to pay: will they pay the price your model needs?
• Workflow fit: does it slot into the customer's day, or does it need a habit they do not have?
• Delivery cost: can you provide the service at a cost that leaves a margin?

Write the hypothesis before the backlog

Before scoping anything, complete one sentence: "We believe [customer] will [behaviour] because [reason], and we will know we are right when [measurable signal] within [time]." If you cannot fill in the signal, you are not ready to build yet. You are still researching, which is fine and much cheaper.

Two hypothetical examples, written the way a team might phrase them:

• "Restaurant managers will book staff shifts through a shared link instead of a group chat. We will know when eight of ten pilot sites are still using it after four weeks."
• "Small accounting firms will pay 900 SEK a month for automated client reminders. We will know when five firms pay for a second month."

Notice that neither sentence mentions features. The features are whatever is needed to produce the signal, and usually that is far less than the backlog suggests.

Do the expensive parts by hand

Much of what looks like software can be done manually behind a simple interface for the first weeks. A person can do the matching. A report can be put together in a spreadsheet and sent as a PDF. A payment link can replace a billing system. Early users care whether the result helps them. You care whether they come back.

No-code tools and carefully applied AI automation make it possible to build a working prototype in days. That speed only pays off if it is aimed at the hypothesis.

Agree the thresholds before launch

Decide in advance which result means continue, which means change direction and which means stop. Teams that skip this tend to read any outcome as encouraging. A threshold set beforehand protects you from your own optimism and from spending another quarter on a question the market has already answered.

When to build properly

Once the core assumption holds, and people use it, pay for it and come back, the priorities change. Reliability, security and scale now matter, and that is when to invest in proper engineering with a team that can own the product long term. The MVP has done its job by showing that the larger product is worth building.