An MVP is a small product that helps test an important business assumption. It becomes expensive when “minimum” refers only to the first estimate while the feature list keeps expanding.
Write the assumption first
State who the product serves, the problem it solves and the behaviour that would justify further investment. Then choose one end-to-end journey that allows that behaviour to occur. A dashboard full of unfinished options is less useful than a complete core flow.
For a booking product, the initial journey might be finding availability, submitting a request and receiving a confirmed outcome. Automated recommendations and advanced reporting may belong in later work.
Separate essentials from future ideas
List each screen, the data it uses and the decisions a user can make. Record who can access it. Write explicit exclusions so a stakeholder's suggestion does not quietly become part of the committed scope.
Some operational requirements belong in the first release even when they are not exciting: a support path, basic monitoring, access control and recovery of important records.
Make quotes comparable
Ask developers to price the same milestones: discovery, working core journey, acceptance testing and deployment. Require assumptions about content, design assets and integrations. Clarify who supplies each item and what happens when it is delayed.
Define acceptance using observable outcomes. “The customer can complete a request and the operator can process it” is clearer than “the system is user-friendly.” Test failure states as well as successful submissions.
The SBA's business planning resources can help organise the business assumptions. Once those are clear, post a development project with a bounded first release and a separate backlog.