How to Scope an App MVP: What to Build Now, Later, or Never
What is an MVP scope, in practice?
An MVP scope is a written list of the screens and features your first release will have and, just as important, the features it will not have. Its job is to prove one thing: that the people you built the app for will use it for the job it is meant to do. Anything that does not help prove that can wait.
Many app budgets are lost before any code is written, in a feature list that grew during planning. This guide walks through how to cut that list to a scope you can build, test and release.
Who is the app for, and what is its one job?
Before listing features, write two sentences: who the app is for, and the one job it has to do better than whatever they use today. "Busy people who want to track expenses" is too broad to scope against. "Freelancers who need to log a business expense in the few seconds after paying for it" gives you something to test every feature against.
If you cannot agree on those two sentences, the feature list is not the problem yet. Talk to the people who would use the app first.
How do you decide what to cut?
Take every feature anyone has suggested and put it into one of three lists.
| List | What belongs here | Example for an expense app |
|---|---|---|
| Build now | Features the core job cannot be done without | Adding an expense and seeing the running total |
| Build later | Features that improve the job once people use the app | Export to a spreadsheet, spending charts |
| Do not build | Features no intended user has asked for | A social feed, badges, a separate web dashboard |
A few rules help.
- If the job still works without it, it is not "build now". Sign-in with several providers, themes and detailed settings rarely belong in a first release.
- Write a reason next to every "build now" feature. If the only reason is that a competitor has it, move it down a list.
- "Build later" is not a rejection. It is a queue you revisit once real users tell you what they miss.
- Write down why each feature was cut. A few months later nobody remembers, and the same argument starts again.
Why count screens, not just features?
A feature list hides work. "User profile" might be one screen or six. A screen inventory lists every screen the first release needs, including the ones that are easy to forget: onboarding, the empty state a new user sees before adding any data, error screens for a failed network call, permission prompts, and account deletion if users can create an account. Google Play requires apps that let users create an account to offer a way to delete it from inside the app and from a web page (account deletion requirements). Each of these takes design and build time.
The inventory is also what a written estimate should be priced against. An estimate without a screen list is a range that moves once building starts.
What should you decide before design starts?
- Platform. Android only, iOS only, or both from one codebase. This affects cost and timeline more than most individual features. Our services page explains how we choose between Flutter, React Native and native builds.
- Accounts. Whether people must sign up before they get any value. Each step before the core job is a point where some users give up.
- Data. What stays on the device, what goes to a server, and whether the first release needs a backend at all.
- Measures. The two or three events that will tell you the app is working, such as how many new users complete the core job in their first session.
How do you know the scope is small enough?
Two quick tests help. Can you describe the first release in one sentence without using "and" more than once? Can a first-time user complete the core job quickly, on an ordinary phone and a slow connection, without instructions? If the answer to either is no, keep cutting.
A smaller first release is also a faster one. The main ThynkBlox blog covers how long an MVP takes to build and why designing before you write code saves money.
What comes after the scope?
Design, build and then release. Release has its own list of requirements that first-time publishers often meet late. We cover them in our Google Play release checklist.
Once the app is built, plan for life after launch: see what app maintenance involves after launch.
Have an idea and a long feature list? Our ideation and discovery work ends in a written MVP definition, a screen inventory and an estimate against that exact scope. Answers to common questions about cost, timelines and code ownership are in our FAQ.