MVP vs full product: how to decide what to build first
Every founder walks in with a vision. 40 features. Three user types. An admin dashboard. Social sharing. Push notifications. A loyalty program. In-app messaging. Analytics. Oh, and it needs to work offline.
And I get it. You've been thinking about this for months, maybe years. The full picture is vivid in your head. It feels incomplete if you cut anything.
But here's what actually happens when you try to build that full vision on day one: it takes twice as long, costs twice as much, and half the features turn out to be wrong because you built them before real users told you what they actually need.
The MVP question isn't really about how much to build. It's about how fast you want to learn.
What an MVP actually is (and isn't)
The term "minimum viable product" gets thrown around so loosely that it's almost lost its meaning. So let me be specific.
An MVP is the smallest version of your product that lets you test your core assumption with real users. One user type. One primary journey. Enough to answer the question: "Will people actually use this and pay for it?"
An MVP is not:
- A prototype. Prototypes are for showing stakeholders. MVPs are for showing customers. An MVP has to actually work.
- A broken product. "Minimum" doesn't mean low quality. It means focused scope. The features you include should work beautifully. You're just including fewer of them.
- A throwaway. A good MVP is the foundation you build on. It's not a separate thing you scrap later. The architecture, the design system, the core flows, all of that should be built to last.
Reid Hoffman's famous quote, "If you're not embarrassed by the first version of your product, you've launched too late," gets repeated a lot. I think it's half right. You shouldn't be embarrassed by the quality. You should be embarrassed by how few features it has. Those are very different things.
The "one user, one journey" rule
This is the framework we use at Rebelled to help founders scope their first version. It's simple, and it works.
Pick one user type. Not three. Not "consumers and businesses." One. Who is the single most important person who will use this app? What do they look like? What's their day-to-day?
Map one journey. From the moment they open the app to the moment they get value. What are the fewest possible steps? What screens are absolutely necessary?
Example: say you're building a fitness app for personal trainers to deliver programs to their clients.
- Full vision: Trainer creates account, builds programs, assigns to clients, tracks progress, sends messages, processes payments, manages scheduling, runs analytics, has an admin dashboard.
- MVP (one user, one journey): Trainer creates account, builds a program, shares it with a client via link. Client views program and marks exercises complete.
That second version tests the core assumption: will trainers actually use an app to deliver programs, and will clients engage with them? If the answer is yes, you build out from there. If the answer is no, you just saved yourself $100k+ and 6 months.
For more on how we scope MVPs and what they typically cost, check out our MVP development page and the MVP cost guide.
When an MVP makes sense
Not every project needs an MVP. But most do. Here's when the MVP approach is clearly the right call:
You haven't validated demand yet
If you're building on an assumption (even a strong one), an MVP lets you test it with real users before committing your full budget. We've seen founders spend $40-60k on an MVP, learn that users wanted something slightly different, pivot, and then build the right product with their remaining budget. Without the MVP, they'd have spent $180k building the wrong thing.
Your budget is under $150k
At this budget level, trying to build a feature-complete product usually means cutting corners on quality. You end up with a lot of features that all feel half-baked. An MVP at this budget, on the other hand, can be genuinely excellent. Fewer features, but each one polished and robust.
You're entering a competitive market
Speed matters when competitors exist. Getting to market in 3 months with a focused product beats getting to market in 9 months with a comprehensive one. The early adopters who will make or break your app care about the core value proposition, not feature parity with established players.
You're a first-time founder
Your first app build will teach you more about product development than any book or course. An MVP lets you go through the full cycle (design, build, launch, iterate) quickly, so you learn what really matters before making the big investment.
When you need more than an MVP
There are genuine scenarios where launching with a stripped-down version would actually hurt you. Here's when to consider building more from day one:
The market expects a certain baseline
If you're building a banking app, users expect security features, transaction history, card management, and support. You can't launch a banking app with just "transfer money" and call it an MVP. Regulated industries and categories with established user expectations often need a higher baseline to be viable.
Network effects are central to your product
Marketplace apps (connecting buyers and sellers, or service providers and customers) often need a critical mass of features to create enough value on both sides. A marketplace MVP that only works for sellers but not buyers isn't really viable. You need enough functionality for both sides to get value.
You have strong validated demand and capital
If you've already pre-sold 500 subscriptions, have $300k in funding, and deeply understand your users from years in the industry, the lean MVP approach might slow you down unnecessarily. Sometimes the fastest path to revenue is building the full v1 and going to market with confidence.
Your competitive advantage IS the comprehensiveness
Some products win because they replace 3-4 separate tools with one integrated experience. If your whole pitch is "everything in one place," an MVP that only does one thing undermines your positioning. In these cases, you might build more features but accept that each one is simpler in v1.
The feature prioritisation framework
Whether you're scoping an MVP or a larger v1, you need a system for deciding what makes the cut. Here's what we use:
Category 1: Must have. Without this, the app literally doesn't function. Users can't complete the core journey. Authentication, the primary user flow, basic data storage. If you remove it and the app stops making sense, it's a must have.
Category 2: Should have. Makes the experience significantly better but the app still works without it. Push notifications, search, filters, profile editing. Important for retention but not required for first use.
Category 3: Could have. Nice additions that improve the experience incrementally. Social sharing, dark mode, customisable settings, advanced analytics. These are your v2 features.
Category 4: Won't have (yet). Features you've explicitly decided to defer. Writing these down is just as important as listing what you're building. It prevents scope creep and gives your team a clear "not now" list.
For an MVP, you build all of Category 1 and maybe 30% of Category 2. For a fuller v1, you build Categories 1 and 2 completely and maybe pick a couple from Category 3 that give you a competitive edge.
The cost reality
Let me give you some real numbers. These are ranges based on what we see in the Australian market for consumer-facing mobile apps:
- Lean MVP: $40,000 - $80,000. One platform (usually iOS first), one user type, core journey only. 8-12 weeks to build.
- Strong MVP: $80,000 - $130,000. Both platforms, one user type, core journey plus key supporting features. 12-16 weeks.
- Full v1: $130,000 - $250,000+. Both platforms, multiple user types, comprehensive feature set. 16-28 weeks.
The question isn't just "how much can I afford?" It's "how much should I spend before I know whether users want this?"
If you're spending $200k before a single real user touches the product, you're making a big bet. Sometimes that bet is justified. But for most first-time founders, starting with a $60-80k MVP and iterating based on real data is the smarter play.
Our MVP cost guide goes deeper on pricing and what influences it.
Don't confuse "simple" with "easy"
Scoping an MVP is harder than scoping a full product. Cutting features requires more product thinking than adding them. You need to know exactly which 20% of features deliver 80% of the value.
The founders who struggle with MVPs are usually the ones who see every feature as equally important. Everything feels essential. Cutting anything feels like compromise.
Here's a question that helps: "If a user could only do ONE thing in this app, what would it be?" Start there. Build that one thing beautifully. Make it so good that users want more. Then build more.
The best v1 products we've built weren't the ones with the most features. They were the ones where the core experience was so tight that users immediately understood the value and came back the next day.
What happens after launch
This is the part most MVP articles skip, and it matters more than the build itself.
After your MVP launches, you should have a 90-day iteration plan. Not a list of features to add, but a framework for deciding what to build next based on real user behaviour.
- Watch what users actually do. Not what they tell you in surveys. Where do they drop off? What features get used daily vs ignored? Where do they get confused?
- Talk to your most active users. The people using your app every day are your product development team. They'll tell you exactly what's missing. Listen hard.
- Measure retention, not downloads. 10,000 downloads means nothing if 95% of users never come back. Day 1, Day 7, and Day 30 retention rates tell you whether your core product works.
- Build the next thing based on data, not assumptions. Your v2 features should be informed by real usage patterns. The things users actually ask for, not the things you assumed they'd want.
The MVP isn't the finish line. It's the starting line. The real product development begins when real humans start using the thing you built. Everything before that is educated guessing.
If you're trying to figure out the right scope for your first version, book a free game plan session and we'll walk through it together. No pressure, no pitch. Just honest advice on what to build first.
