ou have a spec. Forty features, maybe more, pulled from every investor call, every competitor teardown, every late-night idea since the product was a sketch. Your budget covers a third of it. So the real work starts, and it is a cutting job: what ships first, and what waits.
Most advice hands you a checklist of must-haves and nice-to-haves, then calls it done. A checklist can't tell you where your line sits. It doesn't know your validation question, your budget, or the one thing this product has to prove.
Here in Brocoders we've drawn that line under real deadlines: a telehealth platform live in 6 weeks, a route-management SaaS in 3.5 months. Here's the decision rule we use, the two lines that actually matter, and the builds where you can watch it work.
TL;DR: An MVP should include the smallest feature set that answers your one validation question, plus the architecture floor (secure auth, a real data model, access control) that lets the winner scale. It should leave out anything that improves the product without changing what you learn: extra roles, custom reporting, integrations that don't gate validation, and native mobile before responsive web has tested the idea.
What an MVP is actually for (and the scope trap) The MVP Scope Line: keep, defer, floor What an MVP should include What an MVP should not include See it solved: scoping a telehealth MVP to 6 weeks How to prioritize your MVP features, step by step How a discovery phase draws the line for you FAQ
What an MVP is actually for (and the scope trap)
An MVP earns you one thing: evidence. It's the smallest version of your product that lets real users show you whether the core idea holds. The term goes back to Frank Robinson and got popular through Eric Ries and the lean startup movement, and Wikipedia keeps the canonical definition if you want it.
Teams miss in two directions. The first is building too much. Features pile up, the launch slips, feedback arrives months late, and by then the budget went to things nobody asked for. Pendo's Feature Adoption Report found that 80% of features in the average software product are rarely or never used (Pendo, 2019). An overbuilt MVP is that statistic paid for in advance.
The second is building too little. Ship a version so thin it can't do the job, and users leave for reasons that have nothing to do with your idea. You learn nothing. Worse, you read polite interest as demand and build your roadmap on a false positive.
Eric Ries, who popularized the term, warned against reading "minimum" as cheap or rushed. "I hate the idea of 'fail fast,'" he said in an interview on common Lean Startup misconceptions. "The breathing is not the purpose; the sprint is the purpose." An MVP is the smallest amount of design and code that still runs a real experiment, built to a quality that gives you an honest answer.
Both failures come from the same gap: no rule for where the line goes. So here is the rule.
The MVP Scope Line: keep, defer, floor
Every feature in your spec belongs in one of three tiers. We call the sorting method the MVP Scope Line.
Validation Core. The one job your product must do to answer your single validation question. Airbnb's first version let a traveler book a stranger's room. Uber's let a rider request a car and pay for it. Anything outside that core action can wait. This tier stays small on purpose.
Deferrable Layer. Everything that improves the product without changing what you learn: extra user roles, reporting dashboards, third-party integrations, admin polish. Genuinely useful later, invisible to your validation question now.
Non-Negotiable Floor. The architecture underneath everything: secure authentication, a real data model, access control, and room to grow. You keep this tier even while you cut features, because the version that passes its test has to scale on whatever you built it on. Most scope advice skips the floor, which is how teams ship an MVP that wins its test and then buckles the moment real usage arrives.
One question sorts any feature on your list:
| Tier | What lives here | Decision |
|---|---|---|
| Validation Core | The job that answers your validation question | Keep |
| Deferrable Layer | Improvements that don't change what you learn | Cut or phase |
| Non-Negotiable Floor | Auth, data model, access control, room to scale | Keep, always |
Does removing this feature stop you from answering your validation question? If yes, it's Validation Core. If no, but it protects scale or user trust, it's Floor. If no on both counts, it's Deferrable.
Jeff Patton describes the same move in his book User Story Mapping: build the story map, then draw a horizontal line below the backbone, and everything above the line is your release. The Scope Line is that line with the Floor added underneath, so the release survives its own success. Marty Cagan sharpens what the Validation Core has to prove. In his Viable Product versus Minimal Product essay, he argues the question that matters is not "could you use it" but "would you use it," and that the viable part, whether people choose to keep using and paying for the product, carries the highest risk and deserves most of your attention.
What an MVP should include
An MVP should include three things: the validation core, a thin layer that makes the core usable, and the architecture floor that keeps the winner alive.
The validation core, built well enough to sell
Pick the single job your product exists to prove, and build that one job to a quality a real user would pay for or return to. Henrik Kniberg's well-known drawing makes the point: the early version has to be usable and likable on its own terms, not a broken half of the final thing. A skateboard gets someone down the street. Half a car sits in the driveway.
For a booking product, the core is a completed booking. For a marketplace, it's one real transaction between two real users. Build that, and build it so it works.
The thin layer that makes the core usable
A user has to reach the core action and finish it without you standing over their shoulder. That means a sign-in they trust, one clean path in, and one clear result out. A doctor logs in, starts a consultation, and sees it happen. A collector opens the app, gets a route, and marks a stop done. Enough to complete the job once, unaided.
The non-negotiable floor
Cutting features is fine. Cutting architecture is what produces an MVP that passes its test and then can't carry the traffic it just earned. AI has made it easy for almost anyone to ship something that looks like a product, with a UI, payments, and data collection, while quietly missing security, privacy compliance, and any real ability to scale. We call that the architecture gap, and it widens every month.
So the floor stays in every time: secure auth, a data model that can hold more than the pilot, sane access control, and structure a senior engineer would sign off on. Here in Brocoders, AI accelerates the code while architects own the structure. That's the difference between fast and reckless.
What an MVP should not include
An MVP should leave out the entire Deferrable Layer: the features that make the product better without changing what you learn. Every item below is worth building someday. None of it belongs in the version that has to answer your validation question first.
- Multiple user roles before a single role works end to end. Build the admin flow that runs your pilot; add the other roles once the core is proven.
- Custom reporting and analytics dashboards. A founder watching 30 pilot users doesn't need a BI suite; a spreadsheet and event logs answer the early questions.
- Third-party integrations that don't gate validation. If the core action works without the CRM, payroll, or ERP connection, that connection is a phase-two line item.
- Native mobile apps when responsive web tests the same hypothesis. Web ships faster and validates the idea; native comes after the idea holds.
- Admin panels beyond the minimum you need to run the pilot yourself.
- AI features bolted on before the core action is proven. Add AI when it is the validation question, not because the deck promised it.
Run each of these through the decision rule and the answer is the same: removing it doesn't stop you from learning what you set out to learn. So it waits.
You can sometimes defer the backend entirely. A concierge MVP delivers the value by hand, and a Wizard of Oz MVP builds the front end while a person runs the back end manually. Both let you test whether people will use the product before you build the system the real version needs.
One caveat keeps founders honest about how much they can cut. As Kiron Bondale put it, "minimum isn't the same as small." How thin your MVP can be depends on context. A brand new category means low expectations and a genuinely small first release. Replacing an established product means your first version has to meet the incumbent's baseline to be taken seriously, so the Deferrable Layer shrinks. A founder rebuilding a stalled platform, or replacing an enterprise process a compliance team already relies on, sets the floor by what they compete against, not by a feature count.
Cut the features. Guard the floor. Get that order right and the rest of the roadmap takes care of itself.
See it solved: scoping a telehealth MVP to 6 weeks
CoreHealth came to us needing the first version of a doctor consultation platform under a hard deadline. Six weeks, start to live (case study).
The validation question was direct: will doctors and patients actually run a consultation through this? So the Validation Core was the consultation itself. A patient books a slot, a doctor accepts, the two connect and complete the visit. That shipped in the 6 weeks.
The Deferrable Layer waited: specialty-specific workflows, billing integrations, analytics for clinic admins. None of it changed whether the core consultation worked, so none of it made the first cut.
The floor did not wait. This is healthcare, so secure handling of patient data, real authentication, and a data model built to grow were in from day one. The first version had to hold up as the product grew past the pilot, and it did, because the floor was built for more than 6 weeks of use.
A second build makes the same point on a longer timeline. Revenue Boosters, an amusement operator running coin-operated machines across Kentucky, needed a route-management SaaS from scratch. We shipped the MVP in 3.5 months: a web dashboard, mobile apps for the collectors in the field, and route optimization (case study). The core was the collector's daily loop, plan a route and track revenue. Owner David Finley put it plainly: "The whole Brocoders team took this project and made it a complete masterpiece."
It usually comes down to the client's budget and the timeline they need it in. We prioritize with the client by importance from there and cut what doesn't fit. On a recent workforce engagement platform we built, we cut the AI avatar integration from the MVP. On an accounting platform for small business owners, we cut payments entirely and left them for the next phase.
Artem Panasiuk
This answers a fair objection. Marty Cagan argues that a 4-month MVP is a compromise, useful neither as a clean discovery tool nor as a real delivery tool. He is right about the trap. The way out is scope discipline plus a right-sized floor, which lets a real, sellable MVP ship in weeks and serve as both the experiment and the first version of the product.
The pattern repeats because the rule holds. When the floor is right, the Deferrable Layer turns into a roadmap you build against, without a rebuild.
How to prioritize your MVP features, step by step
Here's the method we run before writing a line of code. Frameworks like MoSCoW help you rank a list, but ranking assumes you already know what belongs on the list. The validation question decides that first.
- Write your single validation question. One sentence, one thing you need to learn, phrased so a yes or no from real users would change your next move.
- Sort every spec item with the decision rule. Does removing it stop you from answering the question? Keep, defer, or floor each line.
- Protect the floor. Before you celebrate a short feature list, confirm auth, the data model, and access control are in scope. A lean MVP on a broken foundation is the expensive kind.
- Sequence the Deferrable Layer into phases. Everything you cut goes on a dated roadmap, so cutting feels like ordering, not losing.
- Set your validation metric before you build. Decide now what result counts as proof: activation rate, repeat use, a signed pilot. Otherwise you'll read whatever happens as success.
Do this and the spec stops being a wish list and becomes a build plan with a clear first release.
How a discovery phase draws the line for you
Teams that ship in weeks rarely draw the scope line in their heads. They put it on paper first. That's what a discovery phase is for.
Here in Brocoders, a paid discovery turns a spec into the scope line as a deliverable: a validation question, a user-story map, the three tiers sorted, an architecture floor, a phased roadmap, and an estimate you can take to a board. You walk out knowing exactly what the first release includes, what it leaves out, and what the winner scales on. That's the same document our teams use to hit a 6-week or 3.5-month build, and it's the fastest way to stop arguing about features and start proving the idea.
FAQ
How many features should an MVP have? Fewer than your spec, and exactly as many as your validation question needs. In practice that's often 3 to 5 core features, sorted with the decision rule, plus the architecture floor that never counts as a feature but never gets cut.
What is the difference between must-have and nice-to-have features? A must-have is any feature you can't remove without breaking the core action that answers your validation question. A nice-to-have improves the product but leaves what you learn unchanged. The removal test settles most arguments in a minute.
What should you not include in an MVP? Everything in the Deferrable Layer: extra user roles, custom reporting, non-essential integrations, native mobile when web tests the same idea, and AI features added before the core is proven. Useful later, distracting now.
How do you decide which features go in the MVP? Ask one question of every feature: does removing it stop you from answering your validation question? Yes means keep. No, but it protects scale or trust, means floor. No on both means defer.
How long should it take to build an MVP? With a tight scope and a clear validation question, weeks to a few months. We've delivered a telehealth MVP in 6 weeks and a route-management SaaS in 3.5 months. Timelines stretch when the scope line is never drawn and the spec ships whole.
Should an MVP include AI features? Only when AI is the validation question itself. If the core action works without it, AI belongs in a later phase. Bolting AI onto an unproven core adds cost and risk without teaching you anything new.
Is an MVP the same as a prototype? No. A prototype demonstrates an idea, often without real data or production code. An MVP is a working product real users use, built on a real floor, made to gather live evidence.
Conclusion
AI can generate your feature list now. It writes the specs, the user stories, the tickets, all of it, in an afternoon. The one thing it can't do is decide where your line goes, because that call comes from your validation question, your budget, and your read on the single thing this product has to prove.
That judgment is the job. Draw two lines and the rest gets simple: the Validation Core that answers your question, and the Non-Negotiable Floor that carries the winner. Everything between them waits its turn.
If you want those lines drawn for your product before you spend the budget, a discovery phase hands you the scope line as a deliverable. And when you're ready to compare partners, our guide to the top MVP development companies shows what scope discipline looks like from the outside.