Not all cuts are equal
Every MVP plan gets cut. The question is whether a cut shortens the build or just moves the cost to a worse moment.
A good cut removes an entire surface: screens, states, permissions and tests that now never need to exist. A bad cut removes the thing that stops the remaining product from quietly breaking. The first makes the project smaller. The second makes it look smaller for a few weeks.
The trouble is that both feel identical in a planning meeting. "Skip the admin panel" and "skip the tests" each take a line off the list. Only one of them takes work off the project. If you want the wider picture of what sets a timeline, I've covered that in how fast you can actually ship an MVP; this article is about choosing the cuts.
Cuts that genuinely shorten the build
Extra user roles. Each role is close to a separate product: its own screens, permissions and onboarding, plus rules for how it interacts with every other role. A marketplace with buyers, sellers and moderators is three interfaces and the logic between them. Launch with the role that experiences the core value and play the others yourself, by hand.
Settings and preferences. Every setting is a decision you've declined to make, and each one multiplies the states you have to design and test. Pick a sensible default and hard-code it. If users complain about the default, you've learned something specific. If they don't, you've saved the work.
Admin tooling. At MVP scale, administration can be careful direct access to the database and a short list of written-down procedures. Build internal tools when a manual task becomes frequent enough to hurt. By then you'll know what the tool should do, which you don't today.
Multi-platform at launch. iOS, Android and web together is not one product built three times. It's three sets of platform behaviour, release processes and bugs. A cross-platform framework reduces the duplication but doesn't remove the testing or the store submissions. Choose the platform where your first users already are.
Custom authentication and payments. Both are solved problems with serious consequences when they go wrong. A hosted sign-in service and a payment processor's prebuilt checkout give you password resets, receipts and card handling without owning the security burden. The reasoning behind that choice is in buy vs build vs glue.
Offline support. Working offline means local storage, synchronisation and conflict resolution: deciding what happens when the same record is edited in two places. That is one of the harder problems in app development. Unless the core use happens somewhere without a connection, a clear "you're offline" message is enough for now.
Notifications. Push, email and in-app notifications each bring permission prompts, preferences, templates and timing rules. Start with the one or two transactional emails the product can't function without, and add the rest when you know what users want to be told.
Edge-case flows. Changing an email address, merging duplicate accounts, bulk import, self-service refunds. These are rare at small scale and can be handled by a support email and a person. One caution: check what your platform requires before cutting. Apple's App Store, for example, expects apps that let people create an account to also let them delete it in the app, so that particular flow isn't optional on iOS.
Cuts that feel like savings and aren't
Tests around the core flow. Not full coverage. A handful of automated tests on the path that delivers the value: sign in, do the main thing, see the result. An MVP changes constantly, and each change is a chance to break the one thing that works. Without those tests you find out from a user, or you re-check everything by hand before every release, which costs more time than the tests would have.
Care over the data model. Screens are cheap to redo. Data isn't. Once real users have real records, every structural change is a migration with a chance of losing something. This isn't about designing for scale; it's about getting the shape right. An unhurried session on the core entities and how they relate is some of the best-spent time in the whole build.
Error handling on payment paths. A declined card, a double-tapped pay button, a confirmation from the payment processor that arrives twice or late. Everywhere else in an MVP, a rough edge costs you a little polish. Here it costs you a user who was charged twice, or who paid and got nothing. Those are the failures people remember and tell others about.
Analytics on the core action. An MVP exists to answer a question: do people want this enough to use it? If you can't see whether users complete the core action, and whether they come back to do it again, you've shipped the product and skipped the experiment. You don't need a full tracking plan. You need an event on the core action and on the step before it.
Cut now or keep: the short version
| Item | Decision | Reason |
|---|---|---|
| Second and third user roles | Cut now | Each is nearly a separate product; play the role manually |
| Settings and preferences | Cut now | Hard-code a default; add options when users ask |
| Admin dashboard | Cut now | Direct database access and written procedures are enough at small scale |
| Second platform | Cut now | Adds testing and release work without proving anything new |
| Custom auth and payments | Cut now | Use hosted services; the risk isn't worth owning |
| Offline support | Cut now | Sync and conflict handling are hard; show an offline message |
| Most notifications | Cut now | Keep only essential transactional emails |
| Rare account and data flows | Cut now | Handle by support, after checking platform rules |
| Tests on the core flow | Keep | Protects the one thing that must work through constant change |
| Data model care | Keep | Data is the expensive thing to change once users exist |
| Payment error handling | Keep | Failures here cost money and trust, not polish |
| Analytics on the core action | Keep | Without it, the MVP can't answer its own question |
A method for deciding
Lists like the one above are a starting point, not a rule. Your product may be the exception: a field-service app really might need offline support on day one. So I'd run every item through the same two questions.
- Would the first ten users still get the core value without it? If not, it's part of the MVP. Keep it and move on.
- Does adding it later cost about the same as adding it now? If yes, cut it. If adding it later costs noticeably more, because data has to be migrated, trust has to be rebuilt, or learning has been lost, keep a minimal version.
A settings page costs the same in month three as in week three, so it goes. A sound data model costs far more once there's data in the wrong shape, so it stays. Analytics can be added later, but the weeks of behaviour you didn't record can't be recovered, so the one core event stays too.
Then, for every item you cut, write down two things: the manual fallback (who does this by hand, and how they find out it needs doing) and the trigger for building it (a volume, a complaint, a paying customer who needs it). That turns "we'll do it later" from a hope into a plan.
What to read next
AI features bring their own version of this problem, where the tempting cuts are evaluation, logging and failure handling. That's the subject of why most AI MVPs need a rebuild. The rest of the series is collected under Shipping AI products fast.