US | Product | 2026-08-16

MVP Scoping: What to Cut From Version One

Six features that show up in nearly every first spec, what each one really costs to build and maintain, and the three things that actually have to be there on launch day.

The most expensive thing in a first version is rarely a hard feature. It is a plausible one — something everybody in the room nods at, nobody argues with, and no customer has asked for. It takes three weeks, works fine, and gets used by four percent of your users.

Scoping a v1 is mostly an exercise in saying no to reasonable ideas. Below is a specific cut list, drawn from features that appear in almost every initial spec, along with what each one actually costs.

The six that always feel essential

In-app chat

Two-way messaging between customers and the business sounds like a small screen with bubbles. It is not. Real chat needs unread counts, push notifications with correct deep links, delivery and read state, message ordering under bad connectivity, moderation or at least a report path, and a plan for what happens when nobody on the business side is watching at 9pm. Budget three to four weeks, plus permanent support load. Ship a tap-to-call button and a contact form instead. If customers start asking for threaded history, you have earned the feature and now know what it needs to do.

Social feeds

Any screen where users post content for other users to see brings a content pipeline with it: media upload and resizing, a moderation policy, a reporting mechanism, and blocking. App stores review user-generated content features closely and expect blocking and reporting to exist. Beyond the build cost, feeds have a cold-start problem — an empty feed reads as a dead app, and you cannot seed your way out of it convincingly with fifty users.

Gamification

Points, streaks, badges, and leaderboards get proposed as retention tools. They only retain people who already had a reason to come back; layered on an app with a weak core, they change nothing. They also carry a data cost — every action needs to be logged and scored, rules need tuning, and leaderboards need anti-abuse thinking the day someone realizes they can farm points. Cut entirely. Revisit when you have retention data showing where people actually drop off.

Multi-role admin

This is the biggest silent budget line in the list. "Owner, manager, and staff, each seeing different things" means a permissions model, invitation flow, role assignment UI, per-role screen variants, and a matrix of test cases that grows multiplicatively. For a business with under ten employees, one shared account or a single admin role does the job for months. Model the data so roles can be added later — a role field on the user record and permission checks routed through one function — but do not build the UI now.

Dark mode

The problem is not writing a second color scheme. It is that every custom widget, every hardcoded hex, every image with a baked white background, and every third-party component needs checking, and QA time doubles because each screen is now two screens. A well-structured theme file at build time makes adding it later cheap. Adding it in v1 taxes every remaining week of the project.

Offline sync

Full read-write offline is the hardest item here. Conflict resolution, queued mutations, deduplication on retry, and a UI that honestly represents "not saved yet" is genuinely hard engineering — a month or more, and the class of bug it produces is the worst kind: data loss that shows up intermittently and cannot be reproduced on demand. Most apps need read caching so the last screen still shows something in an elevator, and a clear error when a write fails. That takes days, not weeks.

What actually has to ship

The v1 floor is short:

• Authentication. One method, chosen for your audience. Email and password plus Apple sign-in if you are on iOS with any third-party login. Add password reset and, per store requirements, in-app account deletion. Skip the fourth provider.
• The core job, complete. Whatever the app exists to do — book the appointment, submit the order, log the workout, dispatch the truck — must work end to end with no dead ends. Half a core job is worse than no app.
• Payments, if you charge. If money is part of the job, it is part of v1. Stripe handles the card sheet and the compliance surface; do not build a workaround where customers pay elsewhere and reconcile by hand.
• Notifications tied to the core job. The confirmation, the reminder, the status change. Not a general messaging center.
• A way to reach a human. A phone number or email in settings absorbs the entire class of problems your v1 does not handle yet.

A decision rule that survives contact with stakeholders

Arguments about scope go on forever when the criteria are aesthetic. Force each proposed feature through four questions:

1. Does the core job fail without it? Not "is it worse" — does the primary transaction become impossible? Booking without a date picker fails. Booking without a profile photo does not.
2. Has a real customer asked, in words you can quote? Internal enthusiasm is not demand. A quote from someone who tried to pay you is.
3. Is there a manual version that works below 500 users? Phone calls replace chat. A spreadsheet replaces analytics. Editing a record by hand replaces an admin panel. If the manual version works, it ships first.
4. Does it get cheaper or more expensive to add later? Dark mode and roles get cheaper if the foundation anticipates them. A payments rewrite or an auth migration gets more expensive. Foundation decisions stay in v1; surface decisions leave.

Anything that fails questions 1 and 2 and passes 3 goes on a written "v2 candidates" list. The list matters — people accept a cut far more readily when it is deferred in writing rather than rejected.

The real cost of building the wrong thing first

On a 30 to 60 day build, three weeks of misplaced work is a substantial share of the schedule. But the calendar cost is the smaller half.

The larger cost is that every shipped feature becomes permanent overhead. It appears in every regression test, breaks during every SDK upgrade, needs its own analytics questions, and occupies space in the UI where a customer has to route around it. A chat feature nobody uses still needs its dependencies updated when Flutter moves, still needs its notification handling checked when Apple changes permissions, and still generates the occasional support ticket. You pay for it every year, in perpetuity, for a feature that produced nothing.

It also costs you information. Ship narrow in 30 days and you get real usage data — where people stall, what they tap that isn't there, which step loses them. Ship wide in 60 and you get the same data later, muddied by features that fragment attention, having already committed budget to guesses you can now no longer un-guess cheaply.

The practical version of this: write the feature list, then delete everything that is not authentication, the core job, and payment. Whatever you find yourself unable to delete after ten minutes of arguing with yourself is probably genuinely v1. Everything else has a date, and the date is after launch.