An MVP is not a smaller version of the product you want to build. It is the smallest thing that tests the one assumption your business is riskiest on. Most founders get this backwards and build a shrunken version of the whole vision, which is how three months and a real chunk of budget go into features nobody has asked to use yet. The question worth answering is not what to put in your first version. It is what you can leave out and still learn whether the idea works.
The test for what stays is narrow. Keep only what a user needs to complete the core action once, and what you need to see whether they did. Anything a user does not touch on the way through that single loop can wait. If your product is a marketplace, the loop is one person listing a thing and one person buying it. If it is a tool, the loop is a user doing the one job they came for and coming back to do it again. Draw that loop first, then be suspicious of everything that is not on it.
So what actually gets cut. In practice the first things to go are the ones that feel responsible to build: the account settings page, the polished onboarding, the admin dashboard for yourself, the second type of user, the integrations you might want later, the edge cases nobody has hit yet. You can fake or skip almost all of it at the start. Handle sign-ups by hand. Run the admin side off a spreadsheet. Support one kind of user, not three. None of that is how the product works forever. It is how you find out whether there should be a forever.
Small scope is not the same as rough work, and this is where the advice to "just ship something" leads people wrong. Doing one thing is the discipline. Doing it badly is a different mistake, and a costly one, because a clumsy first version teaches you nothing you can use: people leave and you cannot tell whether the idea failed or the execution did. Cut the number of things you build. Do not cut the quality of the few you keep. The one screen a user actually sees has to work and has to be clear, or the test is contaminated before it starts.
Scope does not creep at the planning stage. It creeps during the build, one reasonable-sounding request at a time. The guard is to write the single assumption down before anyone starts, in one sentence, and hold every new feature up against it: does this help us learn whether that is true, or is it here because it would be nice to have. Most things are nice to have. A team worth hiring will push back on scope you do not need, and that pushback is a sign of a good studio, not friction. If everyone on the build says yes to everything, the budget finds its ceiling fast and you are no wiser at the end of it.
The rest gets built after the loop proves out, in response to what real users do, not the roadmap you wrote before launch. That is the actual payoff of keeping the first version small. You reach the evidence sooner and cheaply, and the second version is shaped by facts instead of guesses. A founder who spends a few thousand learning that the core loop works has bought something real. A founder who spends fifty thousand building the full vision before anyone has used it has bought a guess with a nice finish.
So before you brief a build, do the harder half of the work. Write the one assumption your idea lives or dies on, draw the single loop that tests it, and list everything you are choosing not to build yet. That list is the most valuable thing in the project and the easiest to get wrong on your own, because cutting your own ideas is hard and knowing which cut is safe takes having watched a few of these ship. If you want a second pair of eyes on where the line falls, that is the conversation to have before the building starts, not after the budget is half gone.