Define the repeat value before the feature list
The MVP should centre on the behaviour that makes the product worth paying for or adopting repeatedly. Secondary features matter later if the core workflow has not yet proved useful.
Model accounts and tenancy explicitly
Decide whether the product serves individuals, organisations, teams or a mix. That choice affects data isolation, invitations, roles and billing.
These foundations are expensive to retrofit if the first version assumes every user is independent.
Keep billing proportional to the test
If payment is essential to proving willingness to pay, include the minimum billing flow needed. If the first customers are manually contracted, a sophisticated self-service billing system may not be the best use of MVP time.
Build the operational side too
Someone needs to onboard customers, inspect problems, manage access and support the product. A minimal admin view can be more valuable than another polished customer feature.
Choose architecture for change, not imagined scale
The first architecture should be understandable and maintainable while leaving clear seams for likely growth. Premature distribution and infrastructure complexity can slow learning without reducing real risk.