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

This guide gives you one: five steps that turn a long feature wish list into a first version a developer can price and you can launch.

What an MVP is, and is not

An MVP is the smallest version of your web app that lets a real user complete the core job and lets you learn whether they value it. It is not a prototype, which only shows how something might work. It is also not a rough version of everything. A good MVP does one thing properly.

If you are still deciding whether you need an application at all, start with web app vs website. If you want the full build process from idea to launch, our guide on how to build a web app covers every stage. This article zooms in on the step that decides your budget: scope.

Step 1: name the one core job

Write one sentence in this form: "A [type of user] can [do one thing] so that [result]." If you need the word "and" to finish it, you have two products, and you should pick one.

• "A clinic manager can publish open shifts so that qualified staff claim them without phone calls."
• "A landlord can collect a signed application and screening consent from a tenant in one link."
• "A wholesale buyer can reorder last month's order in under a minute."

Everything in the first version either serves that sentence or waits. The sentence is also your test for feature requests during the build: if a request does not help the user complete the job, it goes on the later list.

Step 2: map the shortest path through it

List the screens a user must pass through to complete the core job once, from arriving to done. This is sometimes called the happy path. Keep it to screens, not features.

For the shift-filling example the path is: sign in, create a shift, staff get notified, a staff member claims it, the manager sees it is filled. Five steps and two user types. Anything not on that path, such as reporting, payroll export, a mobile app or custom branding for each clinic, is a candidate for later.

Walking the path also exposes the questions that change cost. Who is allowed to claim a shift? What happens when two people claim at once? These rules are where development time really goes, so write them down now.

Step 3: sort every feature into four buckets

Take your full wish list and place every item in exactly one of four buckets. Be strict. The fourth bucket is the one that saves the most money.

"Fake it" deserves a closer look. If you expect ten customers in the first three months, you do not need automated onboarding. You need a form and a person. Invoices can be sent from your accounting software. Imports can be a spreadsheet you load for the customer. Each manual step you accept removes a feature from the build, and you automate it later when volume proves it is worth it.

Step 4: add the features nobody lists

Every web app needs a set of basics that never appear on a founder's wish list, and they must be in the scope or the quote will be wrong. Add these before you ask for a price.

• Sign-up, sign-in and password reset, with email verification.
• Roles and permissions. Even two roles, such as manager and staff, need rules.
• An admin area where you can see users, fix data and help a stuck customer.
• Transactional email: welcome, reset, and notifications from the core workflow.
• Error handling and empty states, so the first screen a new user sees is not blank.
• Privacy basics: terms, privacy policy, a way to delete an account.
• Backups, monitoring and a staging environment.
• Payments, if you charge from day one. If you can invoice by hand at first, move this to "fake it".

These basics often make up a large share of a first version. That is normal. It is also why cutting one more "nice" feature matters so much.

A worked example

Take the shift-filling app, and imagine the founder's first list had 24 features. After sorting, it could look like this:

The first version goes from 24 features to six plus the basics. Nothing is thrown away. The "later" list becomes the roadmap, ordered by what the first customers ask for. The example is made up to show the method, but the pattern is common: a first list shrinks a lot once you use the "fake it" bucket honestly.

Step 5: write the scope document

A scope a developer can price is two to four pages. It needs six parts.

1. The core job sentence and who the users are.
2. The happy path, screen by screen.
3. The must-have list, each item with a line or two on its rules.
4. The basics from step 4.
5. What is explicitly out of scope, which is your "later" and "fake it" lists. Writing these down prevents arguments.
6. Constraints: launch date, budget range, systems you must connect to, and any privacy or industry requirements.

Rough sketches of the main screens help a great deal. Pen on paper, photographed, is fine. With this document, different developers will price the same product, and you can compare their answers properly using the method in how to compare web development quotes. For what moves the price itself, see web app development cost.

Next step

Write your core job sentence and your four buckets, even roughly, and send them to us. We will reply with questions about the rules behind each must-have, suggest what else can move to "later" or "fake it", and give you a fixed-scope quote for the first version. Learn more on our web application development page or reach us through the contact page.