You have a list of 40 features. You’ve convinced yourself most of them are essential. Your developer has quoted you $60,000 and five months. Something feels wrong — but you don’t know what to cut or why. This is where most MVPs go off the rails before a single user ever touches them.

Choosing the right features for your MVP isn’t about building less. It’s about building the right thing first.

The Only Question That Actually Matters

Before evaluating any feature, ask: does this prove the core value of my product? Not “does this make it better” — does it prove the thing people are paying for exists and works.

A meal planning app’s core value is saving people time deciding what to eat. Does an ingredient substitution feature prove that? No. Does a weekly meal plan generator prove it? Yes. That distinction — core value versus enhancement — is the filter every feature has to pass before it goes into v1.

If a feature doesn’t directly prove or deliver the core value, it’s v2 at the earliest.

The Feature Prioritization Framework I Use With Clients

Every feature gets evaluated on two axes: how much does it contribute to the core user goal, and how long does it take to build. Plot them on a 2x2 and the answer becomes obvious.

Feature TypeUser ValueBuild TimeDecision
Core workflowHighAnyBuild it
Nice-to-haveLowHighCut entirely
Quick winLowLowMaybe, if time allows
Essential infrastructureHighHighBuild it, plan carefully

Features in the top-left quadrant — high value, high build time — are your v1 non-negotiables. Everything else gets pushed or cut. Not “deprioritized.” Cut.

What Every MVP Actually Needs

There’s a short list of things that have to exist for any product to function and convert. Beyond this list, you’re making decisions specific to your use case.

Authentication. Users need to sign up, log in, and manage their account. This is table stakes — but keep it simple. Email and Google OAuth covers 90% of users. Skip enterprise SSO, magic links, and two-factor for now.

The core workflow. Whatever your product does, it needs to do that one thing end to end. Not beautifully. Not with every edge case handled. End to end.

Basic notifications. Email confirmation on signup, transactional emails for key actions. Not a full notification center. One or two emails.

Payment if you’re charging. If your revenue model requires payment, Stripe integration is v1. Don’t launch a paid product with a “contact us to pay” flow — it kills conversion immediately.

Enough UI to not embarrass you. It doesn’t need to be beautiful. It needs to be usable and not look abandoned.

That’s it. Everything else is a decision, not a requirement.

What Most Founders Try to Build in v1 (And Shouldn’t)

These are the features I push back on most often — not because they’re bad ideas, but because they don’t belong in an MVP:

FeatureWhy It Feels EssentialWhy It Isn’t
Advanced search and filtersUsers will have lots of dataYou have no users yet
Admin dashboardYou need to manage the appManage it manually first
Mobile appEveryone uses their phoneWeb works on mobile. Ship faster.
Team collaborationEnterprise clients need itValidate solo users first
AI-powered recommendationsMakes the product smarterYou need data to train on first
Analytics dashboard for usersThey’ll want to see insightsBuild when you know what matters

Each of these adds weeks and thousands of dollars. Each of them can wait until you have users telling you they need it.

A Realistic MVP Timeline and Budget by Scope

Scope determines timeline. Here’s what honest numbers look like for a focused MVP:

ScopeFeatures IncludedTimelineCost Range
Micro MVPCore workflow + auth only3–5 weeks$4,000–$9,000
Standard MVPCore workflow + auth + payments6–9 weeks$10,000–$20,000
Full MVPAbove + notifications + basic admin9–14 weeks$20,000–$35,000
Over-scoped MVPEverything on the list4–6 months$40,000–$80,000+

The over-scoped MVP is where money goes to die. I’ve seen founders spend $70,000 on a product that needed $15,000 worth of validation first.

The Mistake That Costs the Most

Building features based on what you think users want instead of what they’ve told you they need. It’s the single most expensive mistake in product development — and almost every first-time founder makes it.

The fix is embarrassingly simple: talk to users before you spec the feature. Not after. Before. If five potential users can’t explain why they need a feature in their own words, it’s not v1.

Your MVP is a question, not an answer. Build only what’s needed to ask it.


If you want a realistic feature list and build plan for your MVP — with actual timelines and costs — let’s talk. I’ll help you cut what doesn’t belong and build what actually matters.