What to Build in an MVP and What to Leave Out

What Should an MVP Include?

One workflow, completed: the user arrives, does the thing the product exists for, pays, and comes back. For a booking product that is find–book–pay–remind; for an analytics tool it is connect–see–share. If a stranger can travel that loop unaided and money can change hands, the MVP is functionally complete — a working SaaS MVP with auth, billing and a dashboard is precisely this loop and almost nothing else.

Around the loop, include only its life support: sign-in (email and password is fine), payment through a standard processor, analytics events on the actions that matter, and the transactional emails the workflow cannot function without. That is the whole list. The discipline is not minimalism for its own sake — every omitted feature is a week of runway kept and a variable removed from the experiment you are about to run.

Why Should You Build Less Than Feels Right?

Because feature intuition is measurably poor. Pendo's feature adoption report, analysing usage across hundreds of software products, found 80 percent of features are rarely or never used, and estimated $29.5 billion of public cloud company investment sitting in those ignored features. Those were features that professional product teams were confident about. A founder's pre-launch feature list deserves at least equal scepticism.

The startup version of the same evidence is CB Insights' post-mortem analysis: 42 percent of failures cited no market need. Read together, the two datasets describe the same trap from different ends — teams building more product than anyone had asked for, funded by money that validation should have spent. The MVP's small scope is the structural defence: you cannot heavily over-build a product that only contains one workflow, and the scope discipline pairs naturally with the demand checks in our MVP validation guide.

How Do You Decide What Makes the Cut?

Run every candidate feature through the week-one test: write down, specifically, what launching without it costs in the first week. For most of the list the honest answer is nothing — no user misses an admin panel, a second pricing tier or a settings page in their first seven days. The features whose absence genuinely blocks the core loop in week one are your MVP; everything else is a roadmap entry with a date it must earn.

Apply the filter in order, and be strictest at the top: cut whole user roles before cutting features, because a role is a compound purchase — its own screens, permissions, onboarding and edge cases. The same logic scales the budget, which is why our scope-to-budget guide treats role-count as the first lever: a single-role MVP is routinely half the price of its two-role sibling.

A worked example makes the filter concrete. Suppose a founder briefs a tutoring booking product with a twelve-item list: search for a tutor, view a profile, book a slot, pay, receive reminders, leave reviews, in-app messaging, a tutor dashboard, tutor payout reports, a native iOS app, a referral scheme and an admin panel. The week-one test sorts it quickly. Search, profile, book, pay and reminders are the loop — five items, build. Reviews and messaging are deferrals with an evidence bar attached: build reviews once twenty sessions have completed and there is something to review; build messaging when users demonstrably ask for it instead of emailing. The tutor dashboard and payout reports are a second user role in disguise — the most expensive deferral on the list — so version one serves tutors with a weekly email of their bookings and a manual payout, which costs almost nothing to operate at early volume. The native app, the referral scheme and the admin panel fall to questions two and three: none blocks the loop, and two of the three serve scale that does not yet exist.

The money in that sorting is real. The full twelve-item version is a two-role web application with messaging — the shape of build that sits at the top of any price table, and one that would not fit a $2,500 ceiling in a single phase. The five-item loop is a single-role build of the kind that prices around the middle of the range: across PINCLER's 79 documented projects the median is $1,450 delivered in 13 days, and 55 of the 79 have starting prices of $1,000 or less. The trimmed brief does not merely cost less. It launches weeks earlier and produces a result you can actually read — slots booked and paid for, or not — before the seven deferred items have consumed a single hour of build time.

For each feature, ask in order:
1. Does its absence block the core loop in week one?
       YES → BUILD  ·  NO ↓
2. Will real usage data decide it better than debate?
       YES → DEFER (give it the evidence it must earn)  ·  NO ↓
3. Does it serve scale you do not have?
       YES → CUT  ·  NO → it is probably a phase-two DEFER

What Goes In, What Waits, and What Never Ships in Version One?

Here is the framework applied to the features that appear in nearly every founder's first list. Your product will vary at the edges, but in inbound briefs we review, this table is right far more often than it is wrong.

Which Unglamorous Features Does Version One Genuinely Need?

The cutting instinct, once acquired, tends to overshoot into the support structure — and four unglamorous items should survive every cut. Analytics events, because an MVP without instrumentation is not an experiment, just a small product; wire sign-up, activation, the core action and payment from the first release. Error states and empty states, because a blank screen reads as a broken product to the stranger deciding in thirty seconds. Transactional email — receipts, confirmations, resets — because the workflow silently depends on it. And a feedback path as humble as a mailto link, because week-one users are the cheapest research you will ever have.

None of these is expensive — together they are line items measured in hundreds of dollars inside a fixed-price build — but all are miserable to retrofit under pressure in week two. The distinction worth internalising: features serve users, and instruments serve the experiment. Cut features freely; protect the instruments.

Who Is the One-Workflow Rule For — and When Does an MVP Need More?

The rule fits most founders: SaaS tools, booking products, dashboards, content products and internal tools all have a core loop that one role travels, and they should launch with exactly that. It also fits anyone on a tight envelope, since a single-workflow build sits comfortably inside a $2,500 fixed price.

Three categories honestly need more, and pretending otherwise produces broken experiments rather than lean ones. A two-sided marketplace must serve both sides from day one — thinner versions of two workflows, not one workflow. Regulated products carry compliance scope — consent, records, data handling — that no week-one test is allowed to cut; budget for it and confirm specifics with a licensed advisor. And products whose entire value is an integration need that integration working, however hard it is. Scope up knowingly in these cases, and phase everything else twice as aggressively to compensate. Where the boundary sits between a legitimate MVP and a full product is its own question, covered in MVP versus full product.

What Are the Common Scoping Mistakes?

Scope fails in both directions, though over-building is ten times more common than over-cutting. These six patterns cover most of what we see.

• 1. Building for three user types when version one needed exactly one.
• 2. Shipping without analytics, then launching blind — the un-instrumented MVP teaches nothing.
• 3. Treating the feature list as fixed while the deadline and budget flex — it must be the other way round.
• 4. Cutting the payment flow 'until later' — later, you will be validating a free product nobody was asked to buy.
• 5. Polishing visual design while the core loop still has gaps — strangers forgive plain screens, not dead ends.
• 6. Adding 'just one small feature' mid-build — the phrase that has moved more launch dates than any technology ever has.

PINCLER's Perspective: Scope Is the Price

PINCLER is an AI-first custom software development studio, and our pricing data doubles as a scoping lesson: across PINCLER's 79 documented projects — all fixed-price between $500 and $2,500, median $1,450 in 13 days — what moves a quote is structural scope, not polish. Single-loop categories sit low (websites at a median $1,025, integrations at $1,200), while web apps, the category where second roles and billing complexity live, top the table at $1,925. The dataset is published at our research page.

The practical consequence for founders: every deferral in this article's table is worth real, quotable money. Bring a build/defer/cut list to any studio and you will get a sharper quote at a lower number — and, more importantly, an MVP whose results you can read, because it tested one thing at a time.

The Bottom Line

Build the loop, the payment, the instruments — and defer everything that has not earned its place with evidence. The research says most features go unused and most startups die of no market need; a one-workflow MVP is the cheapest defence against both, and it fits inside a $2,500 fixed price with room to spare.

If you have a feature list, the fastest next step is to run it through the week-one test and then get the survivors priced: a free 30-minute call turns your build column into a written fixed quote within one working day.