“Minimum” and “viable” pull in opposite directions, and most MVP pain comes from resolving that tension in the wrong place — either shipping a toy, or gold-plating a guess.
Cut features, not foundations
The right things to cut from an MVP are scope and polish: fewer user types, fewer edge cases, fewer integrations, a rougher UI. The wrong things to cut are the foundations — a sane data model, authentication done properly, deploys that are automated, the ability to observe what is happening in production.
Foundations are cheap to include now and ruinous to retrofit. Features are the opposite.
Write down what the MVP is testing
An MVP is an experiment. Name the hypothesis — “this segment will pay for this outcome” — and scope to exactly what proves or disproves it. Everything that does not serve that test is a distraction dressed up as progress.
This is what a scope brief and technology blueprint are for: they force the hypothesis and the boundary into writing before the build starts.
Plan the second version while scoping the first
You will not throw the MVP away if the architecture behind it was chosen for where you are going, not just where you are. Decide the cloud and data model with the 10x case in mind, then build the smallest thing on top of it. The MVP earns its keep, and version two is an extension rather than a restart.