Cut the Feature List, Not the Foundation
The instinct in scoping an MVP is to cut everything that isn't essential — which is correct — but teams often cut the wrong layer. Features are cheap to add back later. A data model that was scoped too narrowly to hold the features you cut is not. Before removing something from v1, check whether removing it also removes the need to design for it structurally. If it doesn't, keep the structure and skip the feature.
An MVP Should Be a Question, Not a Smaller Product
The point of a minimum version isn't to ship less. It's to find out something you don't currently know — whether people will pay, whether the workflow actually fits how they work, whether the assumption behind the whole product holds. Scope around the specific question you're trying to answer, and the feature list follows from that. Scope around "the smallest version of the full idea" and you tend to ship something too thin to answer anything.
Some Infrastructure Isn't Premature — It's Insurance
"You aren't gonna need it" is good advice applied to features. Applied blindly to infrastructure, it produces a v1 that has to be substantially rebuilt the moment it works. Authentication that can support a second user role. A database schema that doesn't assume every customer has exactly one location. These aren't scope creep — they're a few extra hours now against a rebuild later, and the difference is usually obvious in advance if you ask which category a given piece of infrastructure falls into.
You Can Know What Version Two Needs Before Version One Ships
Not the features — the shape. What are the two or three ways this product could grow if it works? Multi-user, multi-region, a second market segment, an integrations layer? You don't need to build for all of them. You need to know they exist, so v1's foundations don't quietly rule them out.