The features we tell clients to cut from their MVP, every time

We keep an actual running list, updated after every MVP project, of features that founders assume are essential and that we've almost never seen matter in a first version. It's not a rule against these features existing eventually. It's a pattern we've watched repeat across enough different products that we now bring it up before a founder even asks.

The list keeps growing, but the reasoning behind almost every entry is the same: these features solve a problem the product doesn't have yet, usually a scale problem or a sophistication problem that only shows up once real usage proves the core idea is worth solving it for in the first place.

Password reset flows, profile management, email verification, social login options: this is a substantial chunk of engineering time, and for a huge share of early products, a much simpler mechanism, a magic link, a single shared access code, even a form that emails the founder directly, answers the same early question about whether anyone wants the product at all.

We ask founders what the account system is actually protecting or personalizing at this stage. Often the honest answer is "nothing yet," which means the full system is solving a future problem at the cost of today's launch timeline, and that trade rarely makes sense this early.

A custom-built admin interface for managing users, content, or orders is genuinely useful once there's meaningful volume to manage. Before that point, a spreadsheet, a simple database viewer, or an off-the-shelf tool does the same job for a fraction of the build time, and it can be replaced later without regret once real volume actually justifies something custom.

We've built full custom admin panels for MVPs before agreeing to cut them, and watched founders use them to manage a grand total of a dozen records in the first month. That time would have been far better spent polishing the actual user-facing product those dozen records represented.

Founders often want to build in flexibility early: multiple themes, adjustable notification preferences, customizable workflows, anticipating a diversity of user needs that hasn't actually been demonstrated yet. Configurability is expensive to build correctly and expensive to test across every combination, and it's rarely what an early user is actually asking for when they give feedback.

We push founders to build the single best default experience first, and add configuration only once real users specifically request the ability to change something. Real requests are a far better guide to which settings matter than guessing in advance which ones early users might theoretically want.

Unless the founding team has already confirmed international demand through some other signal, building for a global audience before proving the product works for one market is usually solving tomorrow's problem at the expense of today's launch date. Internationalization done properly is a genuinely significant engineering investment, not a checkbox.

We tell founders to launch for the market they actually understand best and can talk to directly, and revisit international expansion once that market has validated the core idea. Expanding into new markets before the first one is proven usually just means failing in more places at once, without any real efficiency gained.

A polished multi-step onboarding experience, with animations and progress indicators and personalization questions, is a reasonable investment once you know what new users actually get confused about. Before that, it's guesswork dressed up as design, built to prevent problems nobody has confirmed users are actually having yet.

We recommend a bare-minimum onboarding for the first version, then watching real users struggle through it, unscripted, to see exactly where the friction actually is. That observed friction is a far better brief for a polished onboarding flow than anything a team can guess at internally before launch.

Push notifications, in-app notifications, digest emails, SMS alerts: founders often want all of these from day one, worried about under-engaging early users. In practice, one well-chosen notification, sent at the right moment for the right reason, usually does more for engagement than five mediocre channels running simultaneously and diluting each other's impact.

We ask which single notification, if it existed and nothing else did, would most likely bring a user back to the product. Build that one first, and build it well, before adding channels that mostly end up ignored or, worse, annoying enough that a user opts out of all of them at once.

Telling a founder to cut a feature they've been planning for months can land badly if it's framed as "your idea is wrong." We frame it instead as sequencing: not "never build this," but "not yet, and here's specifically what needs to be true before it earns its place in the product." That reframing changes how the conversation lands almost every time.

We write this sequencing down explicitly in the project plan, as a named future phase rather than a vague someday, so a cut feature doesn't feel abandoned. It feels scheduled, conditionally, on evidence that hasn't arrived yet, which is a very different feeling for a founder than simply being told no.

None of these features are permanently wrong to build. They're wrong for a first version whose entire job is answering whether the core idea works, cheaply and quickly enough that the answer still matters when it arrives.

The founders who resist adding these features early tend to ship faster, learn faster, and end up building the eventual full versions of these same features with far better information about what users actually need from them.

We revisit this list with every client after their MVP launches, and it's genuinely satisfying how often a feature we cut turns out, months later, to have been unnecessary even in the full product, not just unnecessary for the first version.

A few have become permanent skeptics of their own original instincts as a result, which is a strange but genuinely useful outcome of the whole process, and one we didn't fully expect when we started keeping this list in the first place.

We keep the full list, with specific project examples attached to each entry, and we walk new clients through it during kickoff now rather than waiting for them to propose a feature we already know we'll want to cut later in the process.