In scope or out?Prove pain first.
What belongs in a real MVP - and what agencies add to inflate the bill before you have a single paying user.
The short version
A real MVP is not a stripped-down version of every feature you can imagine. It is the smallest product that proves people will pay for the problem you solve. The trick is identifying what that is. Most inflated scopes come from agencies (or founders) confusing “phase one” with “everything we might ever need.” Prove pain first. Ship only what validates payment. Polish and growth systems come after proof - not before.
Not sure what belongs in yours? Start with pre-build validation, then MVP design and prototyping before you sign a build scope. Choosing an agency? Read our red-flag checklist first.
I have reviewed hundreds of agency proposals and founder wish lists over 15 years. The pattern repeats: v1 scopes that include social graphs, referral engines, admin portals, dual native builds, the list goes on - for products with zero paying users and unvalidated demand.
That is not an MVP. That is a funded fantasy with a launch date. Most agencies aren't malicious - it's just that complex scope and iterations is how they make money. But you are the one who pays when half those features never get used, or when you run out of runway before you learn whether anyone cares.
Here is how we think about real MVP scope at 44Degrees - including what our Chief UI/UX Designer Zinnia O'Brien calls the pain test, the features that almost never belong in v1, and a simple framework for deciding what to ship first. Once scope is clear, see our cross-platform vs native guide before you lock a tech stack in a statement of work.
The Pain Test: What Users Will Forgive (and What They Won't)
Before you debate feature lists, answer one question: is the problem you solve painful enough that people already spend serious time or money on workarounds? Spreadsheets, manual processes, duct-taped tools, hiring someone to do it - if that is happening, you have a pain signal worth building toward.
When pain is acute, the market will tolerate rough UI, missing polish, and a narrow feature set - for a while. What they will not tolerate is confusion. If onboarding does not explain the value, if the core flow is buried, or if the paywall appears before they understand why they should pay, they leave - and no amount of v2 design budget fixes a v1 they never finished.
“If you are solving a painful problem that people already spend serious time or money trying to solve, the market will forgive a lack of slick design - for a while. However, they will not forgive a confusing onboarding or a paywall that makes no sense.”
Zinnia O'Brien, on what actually belongs in v1.
That principle should drive every scoping conversation. Invest design and engineering where comprehension and conversion matter - core flow, onboarding, and monetisation. Defer the features that make demos look impressive but do not prove anyone will pay.
Eight Features That Almost Never Belong in v1
These show up constantly in agency SOWs and founder decks. Rarely in products that reached product-market fit on a lean first version.
Full social graph and activity feeds
You do not have a community yet. You have a hypothesis that people want to connect around your core job. Prove the job first. Add the network later.
Referral program and invite mechanics
Referrals amplify products people already love. If week-one retention is weak, a referral loop just accelerates churn. Fix stickiness before you ask users to recruit friends.
Multiple onboarding tours for unvalidated personas
Three polished walkthroughs for user types you have not spoken to is theatre. One clear path for your primary user beats twelve screens of explanation. Get clear on who you're targeting.
CMS and content tooling for content you do not have
Founders love building publishing infrastructure before they have anything worth publishing. Hard-code v1 content or use a spreadsheet. Ship the value, not the editorial stack and prove people care before investing further.
Enterprise-grade infrastructure on day one
Kubernetes, microservices, and multi-tenant architecture with zero paying users is billable complexity, not product progress. A monolith on a sensible host is fine until scale is a real problem.
Admin portal with half a dozen user roles
Pre-revenue apps rarely need ops dashboards, moderator tools, and franchise hierarchies in v1. You need one core flow elegantly designed and working well for real customers.
Analytics dashboards before one metric matters
Tracking everything is procrastination dressed as rigour. Pick one primary metric - activation, first payment, week-one return - and instrument that properly.
Dual native iOS and Android builds before pain is proven
Two codebases doubles cost and iteration time before you know if anyone cares. Cross-platform or one platform first is usually the right decision for an unproven product.
If your current scope includes three or more of these, you are probably not scoping an MVP - you are scoping a runway burn. An app UX audit can help you separate what blocks conversion from what just inflates the quote.
Phase Map: What Belongs in V1, V2, and V3
Think in phases, not one mega-build. Each phase has a job.
V1
Prove pain and payment
Smallest version that shows real people will pay for the problem you solve.
Include
- •One core job-to-be-done, end to end
- •Signup and account creation done well
- •Clear onboarding to first value in minutes
- •Paywall or payment signal that matches your model
- •One platform (or cross-platform) - not both native stacks
Defer
- •Growth loops, referrals, and social features
- •Admin tooling beyond what you need to operate manually
- •Scale infrastructure and edge-case coverage
V2
Retention and monetisation
Turn early proof into repeat usage and better unit economics.
Include
- •Onboarding and paywall refinements from real drop-off data
- •Retention hooks: notifications, habits, saved states
- •Pricing experiments and plan structure
- •Key integrations your best users actually ask for
Defer
- •Full rebrand or design system overhaul
- •Platform expansion before retention is stable
- •Feature sprawl to please every early feedback thread
V3
Growth systems
Layer distribution and polish once the funnel converts and retains.
Include
- •Referrals, partnerships, AI Discovery & ASO at scale
- •Second platform or native rebuild if data supports it
- •Admin, analytics, and ops tooling built for volume
- •Design polish that matches your category leaders
Defer
- •Building growth before the product earns it
- •Premature enterprise features without enterprise customers
How to Decide What Stays in Your MVP
When a feature lands on the table, run it through three filters. If it fails any of them, it probably does not belong in v1.
One core job-to-be-done
Can you describe the primary outcome your user gets in one sentence? Every v1 feature should serve that job directly. If you need a paragraph to explain why a feature matters, it is v2 at best.
One primary metric
Pick the number that tells you whether v1 worked: first payment, activation rate, week-one return, or trial-to-paid conversion. If a feature does not move that metric, defer it until you have proof.
One platform if possible
Cross-platform or a single native build beats dual native stacks before you have paying users. Platform expansion is a v2 or v3 decision driven by data, not a day-one default.
Vibe coders planning to build themselves should apply the same filters before prompting another feature into existence. Design and prototyping for vibe coders helps you lock scope and UX before you burn months on the wrong build.
When to Pivot vs When to Polish
Founders often polish when they should pivot, or pivot when they should fix onboarding. The signals are different. Use this table after you have real users - not friends humouring your demo.
| Signal you are seeing | Likely move | Pivot or polish? |
|---|---|---|
| Users complete signup but never reach first value | Polish onboarding and core flow | Polish |
| Users reach first value but do not return in week one | Polish retention loop and value proposition clarity | Polish |
| Users love the concept but say they would not pay | Pivot pricing, positioning, or target segment | Pivot |
| Users pay once and churn immediately | Polish paywall, onboarding, and delivery of promised outcome | Polish |
| Target users say the problem is not painful enough | Pivot problem, audience, or core job | Pivot |
| Strong engagement from the wrong audience | Pivot positioning and acquisition, not more features | Pivot |
| Competitors solve the same job with a simpler product | Polish scope down to your sharpest differentiator | Polish |
| No one converts after 50+ qualified conversations | Pivot or NO-GO - do not polish your way out | Pivot |
If you are stuck in the pivot-or-polish grey zone, that is what structured validation is for - a GO, PIVOT, or NO-GO decision backed by real data, not gut feel after a $150K build.
Scope It Right Before You Build
The cheapest time to trim bloat is before anyone writes code. These are the paths we see work most often:
App idea validation
Pressure-test demand and scope before you commit budget. GO, PIVOT, or NO-GO in 2-4 weeks.
App MVP design
Full UI/UX for exactly what belongs in v1 - not a feature laundry list.
Design for vibe coders
Strategy, design system, and build-ready prototype before you vibe code the wrong thing.
App UX audit
Already shipped? Audit onboarding, paywall, and core flow before you add more features.
FAQ
What actually belongs in your MVP?
How many features should be in your MVP?
Should I include admin dashboards and analytics in v1?
When should I pivot vs polish my MVP?
Do I need polished design before launching an MVP?
Should MVP design come before I sign a development contract?
Not sure what belongs in your MVP?
Book a free 30-minute strategy session. We will review your scope and tell you what actually needs to ship in v1.
No obligation. 30-min call. 100% free.