How to Scope a Web App MVP: What to Build First (and What to Cut)

The most expensive mistake in software development isn't building the wrong feature. It's building 40 features when 4 would have told you whether the core idea works.

MVP scoping is not about cutting corners. It's about being precise about what question you're trying to answer with the first version of your product — and building only what's necessary to answer it. This guide gives you a framework for doing that.

What MVP Actually Means

"Minimum Viable Product" has been so misused that it's worth restating: an MVP is the smallest version of your product that can deliver your core value proposition to real users and tell you whether they care.

It is not:

• A rough prototype with known bugs you plan to fix later
• A stripped-down version of a fully designed product
• An excuse to skip proper engineering
• A list of features you wrote on a napkin without thinking about what you're validating

The word "viable" is load-bearing. An MVP needs to actually work. It needs to be deployed to production. Real users need to be able to use it and give you real signal. A prototype that crashes or has a broken checkout flow gives you no useful data.

The word "minimum" is equally important. Every feature you add before launch is a feature you might have learned you didn't need. That's time and money spent on assumptions you hadn't yet validated.

The One Question Your MVP Should Answer

Before you write a feature list, write down this sentence and finish it:

"We'll know this product is worth building if [specific, measurable outcome] happens within [timeframe]."

Some examples of good core hypotheses:

• "Users will complete onboarding and return to the app at least 3 times in the first week."
• "At least 20% of sign-ups will convert to a paid plan within 30 days."
• "Clients will prefer using the portal to emailing us for project updates."

Your MVP needs to include only what's necessary to test that hypothesis. Anything that doesn't contribute to the test is a candidate for v2.

The Feature Prioritisation Framework

Run every proposed feature through these four questions:

1. Does it enable the core user flow? If a user can't complete the primary action your app exists to support, you don't have an MVP. These features are non-negotiable.

2. Does it remove a blocker to adoption? Some features aren't part of the core flow but are required for a user to actually trust the product enough to use it — email verification, password reset, basic error states. These belong in v1.

3. Does it generate data that tests the hypothesis? Some features don't serve users directly but tell you whether your hypothesis is correct — usage analytics, basic admin tooling to see what's happening. These have a case for v1.

4. Everything else. If a feature fails all three questions, it goes on the v2 list. This includes: notification preferences, social features, advanced filtering and search, export functionality, white-labelling, mobile apps, API access for third parties, and most reporting features.

Must-Have vs Nice-to-Have: Where the Line Usually Falls

This is how the list tends to shake out for a typical SaaS or client-facing web app:

Must-have in v1:

• User sign-up and login (email/password, optionally Google OAuth)
• The core feature (the one thing the app does)
• Ability to save and retrieve user-specific data
• A way to pay or onboard if that's central to the hypothesis
• Basic error handling and empty states
• A way for you (the operator) to see what's happening

Nice-to-have, defer to v2:

• Notification preferences and email digests
• Advanced search, sort, and filter
• Activity history and audit logs
• Onboarding tours and tooltips
• Referral system, sharing features
• Mobile app (responsive web is sufficient for most MVPs)
• Comprehensive admin reporting
• Integrations with tools that are "useful but not essential"

A useful pressure test: ask "if we launched without this, would our target users refuse to use the product?" If the answer is no, it's a v2 feature.

The Real Cost of Adding Features Post-Launch vs Upfront

There's a persistent belief that adding features later is cheaper than including them upfront because you "only pay for what you need." This is often wrong.

Features added after launch have to work with an existing data model, an existing API contract, and an existing UI system. If the data model wasn't designed with that feature in mind, you may be looking at a migration. If the API contract doesn't support it, you may need to version your API. If the UI system used different patterns, you're now maintaining inconsistency.

Understanding the full cost of web app development helps clarify why getting scope right upfront matters so much — the cost of rebuilding something that wasn't designed for a feature is often higher than building it correctly in the first version.

The real calculus:

• Features that were always planned but deferred: relatively cheap to add later — the system was designed with them in mind
• Features that genuinely weren't anticipated: can require significant rework to add cleanly

This is why good discovery matters. A competent agency will ask "what are you planning for v2?" not to pad the scope, but to design the data model and architecture to accommodate v2 without a rebuild. You don't need to build v2 features upfront, but you should design for them.

How to Know When v1 Is Enough

Two traps pull in opposite directions:

Under-building: Launching something so stripped down that users can't actually experience the value. This gives you negative signal that isn't real — users didn't use it because it was unusable, not because the idea was bad.

Over-building: Spending 6 months building every feature before any real user has ever seen the product. By the time you launch, you've built things nobody wanted and skipped things people needed.

v1 is enough when:

• A user can complete the primary flow from start to finish without assistance
• The core value proposition is actually experienced, not just gestured at
• You have a mechanism to understand what users do (even just basic analytics)
• The app is stable enough that bugs won't invalidate your signal

It's not enough when:

• The "core feature" is still behind a placeholder
• You're relying on manual workarounds to simulate functionality that should be automatic
• Users need help from you to complete a flow

Getting Your MVP Built

Scoping an MVP well is a skill that takes practice. The tendency — especially for first-time builders — is to keep adding features because each one feels obviously necessary. The discipline is in defending the cuts.

The scope of your MVP also has a direct impact on how long it takes to build — a disciplined MVP can ship in 4–6 weeks; scope creep can turn the same project into a 6-month effort.

Our Web App MVP package is designed for exactly this: a scoped first version, fixed price, deployed to production. The engagement starts with a scoping session where we work through your hypothesis, map the core flows, and draw the line between v1 and v2 — before a line of code is written.

If you're earlier in the process and want to talk through your idea before committing to a scope, get in touch. We're direct about what belongs in v1 and what doesn't, even if that means quoting a smaller project. You can also explore our full custom development service if your scope is beyond a standard MVP.

For a broader introduction to the web app development process, see our complete guide to custom web app development.