MVP Scoping for First-Time Founders: What to Build First (and What to Cut)

The single most common mistake we see in first product conversations is scope, not technology. Founders arrive with a full feature list — social login, an admin dashboard, push notifications, in-app chat, multi-language support — for a product that hasn't yet proven anyone wants the core idea. An MVP's job is to test the core idea as cheaply and quickly as possible, not to arrive fully formed.

Start with one user, one journey

Pick a single primary user and trace the one path that delivers your product's core value, start to finish. Everything that isn't on that path is a candidate for v2. If your product has two very different user types (say, a marketplace with buyers and sellers), you often still need to build for both to make the loop work — but keep each side's version of that flow as narrow as possible.

The three-feature test

If you can't describe your MVP in three features or fewer, it isn't scoped yet. This isn't a rule about counting — it's a forcing function. Try to state your MVP that way, and the features that don't fit reveal themselves as things you're building because they feel important, not because the launch depends on them.

Common things to cut from v1

• Every social login provider — pick one or two (Apple is required if you offer any third-party login on iOS; add Google as the common second option) instead of five
• A custom admin dashboard — a tool like Retool, or even direct access to Firebase/Supabase's own console, covers early operational needs
• Push notifications, unless the core loop depends on real-time alerts
• In-app messaging or chat between users
• Multi-language support before you know which markets matter
• Building both iOS and Android simultaneously, unless your audience is genuinely split — most early apps skew heavily to one platform

What not to cut

• Onboarding that actually explains the product's value — a confusing first five minutes kills more MVPs than missing features do
• A working payment or subscription flow, if the product is meant to make money — testing willingness to pay is often the entire point of the MVP
• Basic analytics instrumentation from day one, so you have real usage data instead of guesses when deciding what's next
• Account deletion, if you support accounts at all — Apple requires it for App Store approval, and Android increasingly expects it too
• Crash reporting — you cannot iterate on a product you can't see failing

Build vs. buy for MVP infrastructure

Almost nothing about authentication, payments, or basic backend infrastructure is worth building from scratch at MVP stage. Managed auth (Firebase Auth, Clerk), subscription/entitlement management (RevenueCat), and a managed backend (Firebase, Supabase) let a small team spend its limited engineering time on the parts of the product that are actually differentiated, instead of reimplementing solved problems.

A scope example

As an illustration: a founder wants a booking app for independent fitness instructors. The full vision includes payments, reviews, recurring class packages, waitlists, instructor payouts, and a marketing website with SEO-optimized instructor profiles. A defensible MVP scope is: instructor creates a class with a time and price, a client books and pays for one class, both get a confirmation. That's the entire loop. Reviews, packages, waitlists, and payouts are all real features — for v2, once the core loop has proven that instructors and clients will actually use it.

Signs you've overscoped

• You're describing your MVP with an "and" more than twice — a real MVP description is usually one sentence, not a list
• You're designing an admin dashboard before you have a single real user to administer
• You're building settings and customization options for preferences no user has actually asked for yet
• You're planning both platforms simultaneously with no clear reason your audience needs both on day one
• Your team can't agree on what the MVP even is — that's a scoping problem, not a communication problem

How long should this actually take

A properly scoped MVP — one core journey, managed infrastructure for auth and payments, a single primary platform — is realistically a six-to-ten week build from a finished design, not a six-month one. If your MVP timeline is stretching toward six months, that's usually a sign the scope has quietly grown past "minimum" rather than a sign the product is unusually complex. It's worth revisiting the three-feature test at that point rather than pushing forward on the original plan.

The goal of an MVP isn't to be small for its own sake — it's to get real usage data as fast as possible, so the next round of decisions is based on what people actually do instead of what you assumed they'd want.