How Much Functionality Does an MVP Really Need?

Ask a founder how big their MVP should be, and they’ll usually answer in terms of features: three screens instead of ten, one user type instead of four. That’s a real question, and worth getting right. But it’s not the whole question.

There’s a second decision hiding inside every one of those features, and it gets far less attention: once a feature exists, how complete does it need to be?

A product can have exactly the right number of features and still be over-built, because each one was made more capable than the test actually required. Or it can have the right number of features and still fail users, because one of them was cut so thin it doesn’t actually work. Both are functionality-depth problems, not feature-count problems, and they need a different kind of decision.

Feature Count vs. Feature Depth — Not the Same Question

It helps to separate the two clearly, because they get conflated constantly in scoping conversations.

Feature count asks: how many distinct capabilities does version one include? Do we need messaging, or can that wait? Do we need a mobile app, or is web enough for now? That’s a breadth question — how wide the product is.

Feature depth asks something different: once you’ve decided a feature is in, how much of that feature actually ships? “We have search” can describe two extremely different products. One means a text box that matches titles against a query. The other means a text box backed by filters, sort order, saved searches, typo tolerance, and autocomplete suggestions. Both are honestly “search.” They are not close to the same amount of work, and — this is the part that gets missed — they are not always the same amount of validation value either.

If you’re weighing how many features to include at all, that’s really a breadth conversation — see our related post on minimum scope for a software MVP, which covers how much is enough at the whole-product level. This post is about what happens after you’ve already decided a feature belongs — how far to take it.

Why Depth Gets Overlooked

Most MVP-scoping conversations naturally gravitate toward the feature list. It’s the part that’s easy to write down, argue about, and cut from a roadmap. “Do we need X” is a yes/no question, so it feels resolved once you’ve answered it.

But saying yes to a feature doesn’t answer how much of it to build. That decision usually gets made implicitly, by whoever happens to be building it, under whatever assumptions they’re carrying that day — a developer defaults to “do it properly,” a designer defaults to “make it feel complete,” and neither is wrong exactly, but neither is checking the decision against what the MVP is actually supposed to prove.

That’s how founders end up with an MVP that has the right feature list but still took twice as long and cost twice as much as it should have — because each feature quietly grew past what the test needed while nobody was tracking it as a separate decision.

A Framework for Deciding Depth

Before adding capability to any single feature, ask one question: is this depth needed to test the core hypothesis, or is it here to make the product feel finished?

Work through it feature by feature:

1. Name what the feature has to prove. Not what it should eventually do — what it needs to demonstrate in this version. A booking feature might need to prove that people will complete a booking online at all. It does not need to prove that they’ll enjoy filtering bookings by six different criteria, because nobody’s tested whether they book online yet.

2. Identify the smallest version that still produces an honest result. Honest is the operative word — not the smallest version that technically runs, but the smallest one that doesn’t mislead a user or generate false signal. A shallow version that silently drops half of submitted data isn’t minimal, it’s broken.

3. Check whether more depth would change the outcome you’re measuring. If adding filters to search wouldn’t change whether people search at all, filters are polish for this release, not a requirement.

4. Flag depth that exists purely for polish, and hold it deliberately, not by default. “We’ll add sorting later” only works if it’s a decision someone made on purpose, not a gap nobody noticed until a user complained.

This is the same logic that applies to picking which features belong in the MVP at all — our piece on identifying the core feature of your MVP walks through that upstream decision, and the depth framework above is really the same test applied one level down, inside a feature you’ve already decided to build.

Bare Functional vs. Fully Featured: A Comparison

Here’s what that distinction looks like across a few common feature types. “Bare functional” is the minimum that still works honestly for a real user; “fully featured” is where most teams eventually land, just not on day one.

Feature	Bare functional	Fully featured	What an MVP typically needs
Search	Keyword match against titles	Filters, sorting, saved searches, autocomplete	Bare functional — enough to prove people search at all
User onboarding	Email/password sign-up, one confirmation step	Social login, guided tour, progress checklist, email drip sequence	Bare functional, unless drop-off at sign-up is the specific risk being tested
Notifications	In-app or single email alert on key event	Push, SMS, email, in-app, with per-channel preferences	Bare functional — one reliable channel beats four unreliable ones
Payments	One payment method, manual receipt	Multiple methods, saved cards, subscriptions, invoicing, refund automation	Bare functional if the hypothesis is “will people pay,” not “which payment method do they prefer”
Reporting/analytics	A handful of hard-coded numbers on a dashboard	Custom date ranges, exports, drill-downs, saved views	Bare functional — enough to show the founder and early users the numbers that matter
Admin/back office	Manual review via database or a simple internal screen	Full permissions system, audit logs, bulk actions	Bare functional, often even manual, since no one but your own team touches it early on

Notice the pattern: in almost every row, the fully-featured version isn’t wrong to build eventually — it’s just evidence you don’t have yet. Building it now spends budget on a bet (“customers will want saved searches”) before you’ve confirmed the smaller bet (“customers will search at all”).

When It’s Worth Going Deeper Early

This isn’t a rule that every feature should be as thin as possible no matter what. Sometimes depth is exactly what the test requires.

• The feature is the hypothesis. If your whole product is an AI-matching engine, “basic matching” that’s obviously worse than a spreadsheet won’t earn a fair test — the core mechanism needs to be genuinely good, even if everything around it is bare.
• A shallow version would be actively misleading. A payments flow that “works” but silently fails on certain card types isn’t minimal, it’s unreliable, and unreliable results are worse than no results.
• Regulatory or safety requirements apply. Depth around data handling, consent, or financial compliance usually isn’t optional just because it’s not the feature you’re testing.
• The shallow version would embarrass the product in front of the exact users you need to convince. There’s a difference between “simple” and “obviously unfinished” — the line moves depending on who’s judging it.

Outside of those cases, the default should lean toward bare functional, then let real usage tell you which features earned more investment. If breadth — how many features make the cut in the first place — is the part you’re still deciding, that’s the question our companion posts on keeping an MVP simple and trimming an MVP idea down before development are built to help with, alongside the scope-level piece linked above.

Putting It Into Practice

Before development starts, walk your feature list a second time — not to add or remove features, but to set an intended depth for each one. Write it down next to the feature, one line: “search — keyword only, no filters,” “notifications — email only, no push.” That single sentence per feature does more to control scope creep than most kickoff meetings, because it turns “how much is enough” from a live debate during development into a decision that was already made.

Frequently Asked Questions

How much functionality does an MVP need?

An MVP needs enough functionality in each feature to let a real user complete the core action honestly, without the software breaking, misleading them, or requiring workaround steps outside the product. Beyond that, extra depth should only be added if it changes what you learn from the test.

What is the difference between how many features an MVP has and how deep each feature goes?

Feature count is about breadth — how many capabilities exist at all. Functionality depth is about how complete each individual feature is once it exists. A product can have very few features that are each built out fully, or many features that are each shallow — depth and count are separate decisions.

Can an MVP feature be too basic?

Yes. If a feature is so stripped down that it produces wrong results, silently fails, or forces the user to do extra work outside the app to get a correct outcome, it is not a minimal version of the feature — it is a broken one. That is a different problem from a feature simply being simple.

How do I decide how deep a specific MVP feature should go?

Ask whether the added depth is needed to test your core hypothesis or whether it exists to make the product feel more finished. If removing that depth would change what users do or what you learn from watching them, keep it. If it would only change how the product feels, it can usually wait.

Should search, filtering, and sorting all be in the MVP?

Not necessarily as a set. A basic keyword search might be enough to prove people want to find things in your product. Filters, sorting, saved searches, and autocomplete are usually refinements that matter once you already know search is used — build them once you have evidence, not by default.

Does building shallow features first save money?

It usually saves both money and time, because full-depth versions of every feature take longer to build and test than a working core version of each. The bigger benefit is speed of learning — you find out sooner whether the feature is even worth deepening.

What happens if I under-build a feature's depth?

Users hit a wall where the product can't do something they expected, and you either lose them or scramble to patch it mid-launch. This is different from a feature being simple by design — it's a sign the minimum bar for that particular feature was set below what the core journey actually required.