Nobody sets out to build a v2 product on an MVP budget. It happens one reasonable-sounding addition at a time. By the time it's obvious, you've already paid for it, in time and in money. Here are six moments that mean it's already happening, and what to do instead.
1. "While we're in there" is showing up in your notes
This is the single most reliable tell. "While we're building the signup flow, we might as well add social login too" sounds free. It isn't. Every "while we're in there" is a separate decision, a separate edge case, a separate testing surface. Heard this phrase twice in one planning conversation? Stop. Write it on the "not in v1" list instead.
2. You're designing for a user who doesn't exist yet
Admin dashboards, permission tiers, multi-team support: all genuinely necessary, someday, once your product has paying customers who need them. Building them before you have one real user proves nothing except that you're capable of building them. Ship the one-user flow first. Let your actual first customers tell you what the second role needs to do.
The tell is usually a sentence that starts with "well, eventually a manager would need to..." Maybe. But you don't have a manager yet, and the manager you eventually get might need something completely different from the one you're imagining now — a different approval flow, a different set of fields visible, a different notion of "team" entirely. Building the second role from imagination instead of from an actual second user is how you end up re-building it anyway, just later and more expensively.
3. Every feature has an "in case" attached to it
"In case someone wants to export their data." "In case we need to support teams later." Every "in case" is a bet on a future you can't see yet, paid for with certainty today. The whole purpose of an MVP is replacing "in case" guessing with real user behavior, as fast as possible. Build for cases that haven't happened, and you've stopped building an MVP.
4. Your core flow keeps getting interrupted by new requirements
If the one thing your MVP needs to prove keeps getting pushed back because something else feels more urgent, the urgency is the problem, not the backlog. A scope that can't stay focused on its core flow for two weeks won't stay focused for six.
5. You're asking "should this be configurable?"
Configurability is a v2 problem. An MVP makes the decision; it doesn't hand the user a setting. Every toggle, preference, or admin-configurable option is scope added on behalf of a use case nobody's validated yet. Pick a default. Ship it. Add the setting later, if real users actually ask.
Here's what this looks like once it's accumulated in actual code — a settings object that grew one "just in case" at a time, none of it driven by a real user asking for it:
const workspaceSettings = {
allowGuestInvites: true,
requireTwoFactor: false,
enableSlackSync: false, // nobody's asked; maybe someday
maxSeatsPerTeam: null, // "in case we need tiers later"
customBranding: false, // competitor has this, so...
exportFormat: "csv", // could also be json, xlsx — undecided
};
Every line is a decision an MVP shouldn't have deferred to a setting. allowGuestInvites: true — is that actually configurable, or did nobody decide? maxSeatsPerTeam: null is the clearest tell of all: a field that exists for a tier structure that doesn't exist yet. Each one of these is a small, reasonable-sounding "while we're in there." Together, they're a v2 product's settings page, built before the v1 product has a single user.
6. The estimate keeps growing without the core flow changing
If your one-user, one-flow description hasn't changed since week one but the estimate has gone up twice, the scope grew somewhere you weren't watching. That's not a dev team problem. It's a sign the "not in v1" list stopped being enforced. Go back to it.
What to do instead
All six are fixable the same way. Keep a visible "not in v1" list. Treat every new idea as something to add to that list, not to the current sprint. The goal was never to stop having ideas; good ones will keep coming. The goal is to ship the thing that proves your core flow works, then decide what's actually worth building next with real user behavior in hand, instead of guessing twice.