We've scoped and built dozens of MVPs. The ones that fail almost never fail because of technical problems. They fail because the scope was wrong from the start.
The MVP trap
A client comes with a 48-page requirements document and calls it an MVP. Everything is "must-have." The authentication system needs to support SSO, OAuth, passwordless, and two-factor. The dashboard needs 14 chart types. The notifications system needs email, SMS, push, and in-app.
That's not an MVP. That's a full product. And it will take 12 months and probably never ship.
The one-sentence test
A valid MVP can be described in one sentence: "A tool that lets [specific user] do [one core action] so that [one measurable outcome]." If you can't describe it in one sentence, the scope isn't minimal enough.
The three-column exercise
We run every client through three columns: Must Have (MVP fails without it), Should Have (makes the MVP significantly better), Nice to Have (everything else). The rule: the Must Have column should feel uncomfortably small. If it doesn't, you haven't cut enough.
Feature dependencies are scope creep in disguise
"We need the API to support pagination before we can build the list view." Do you? Can the list view load all 20 items for now? Almost every technical dependency in an MVP is a future-proofing decision masquerading as a requirement. Challenge every one.
Ship ugly
The first version doesn't need to be beautiful. It needs to prove the hypothesis. We've shipped MVPs with hardcoded data, manual processes behind the scenes, and placeholder UI. Users don't care — they care about whether the core value proposition works.