Mobile app scope is the written statement of which jobs the app will do in its first release and which it will leave for later. If the scope isn't clear, budget, timeline and expectations keep drifting; the team drags on for months with a project it calls "almost done." In this article we explain a simple method for defining scope, the MVP concept and the traps people commonly fall into.
What MVP means, and what it doesn't
MVP (Minimum Viable Product) means "the smallest usable product." In other words, a first release that actually does the core job, is mature enough to hand to real users, and is stripped of everything unnecessary.
An MVP is not a half-finished app. It has few features, but those features work completely and reliably. The MVP of a dealer ordering app can't be "you can place orders but prices display incorrectly"; it should be "you can only place orders, but prices, stock and the cart work flawlessly."
Four steps to defining scope
1. Write a one-sentence goal. "This app makes [person]'s [job] easier by [means]." For example: "It lets service technicians close work orders in the field without paper forms." Any feature that doesn't serve this sentence should be questioned for the first release.
2. Write out a day in the user's life. What does the person who will use the app do in the morning, where do they get stuck during the day, what do they hand in at the end of the day? This story reveals the screens that are truly necessary.
3. List the features, then sort them. Write down every feature you can think of, then put each one into one of four groups:
| Group | Meaning | Example (field app) |
|---|---|---|
| Must have | Without this, the app doesn't serve its purpose | Work order list, closing, photos |
| Should have | Important, but can be handled with a workaround for now | Customer signature |
| Nice to have | Adds value, but can wait | Route optimization |
| Not now | The subject of a different project | Staff leave requests |
The first release should be limited to the must-haves and some of the should-haves.
4. Also write down what's left out. In the scope document, the "not in this release" section is as important as the scope itself. It prevents the "but we talked about this" argument months later.
What's usually unnecessary in the first release
In our experience, the features that make it into the first release but get little use are typically:
- Detailed reporting screens (reports are usually easier to read on a desktop, in the admin panel)
- In-app messaging or chat
- Complex personalization and theme options
- Social media sharing
- A multilingual structure (if one language is enough)
- Notifications for every event
None of these are bad ideas; they just risk getting in the way of the core job in the first release.
Don't forget the invisible scope
Scope isn't made up only of the screens users see. Work that is often forgotten but drives budget and timeline:
- Admin panel. Who will manage the app's content, users and permissions, and from where?
- Integrations. Will data come from the ERP, the accounting software or an existing portal? These connections often take as much effort as the app itself; integration work should be in scope from the start.
- User management. Sign-in, password reset, account closure, roles and permissions.
- The store process. Developer account setup, privacy declarations, review. Details are in our article on the app store publishing process.
- Maintenance. Keeping up with operating system updates after launch.
How do you prevent scope creep?
New ideas naturally come up while a project is under way; what matters is how they are handled.
- Don't reject new requests; add them to a "next release" list.
- If a change absolutely must go into the current release, openly discuss what will come out in exchange or how much the timeline will extend.
- Look at a working interim build at short intervals. Seeing something tangible leads to much clearer decisions than debating on paper.
Checklist
- Has a one-sentence goal been written?
- Have the primary user and their day been described?
- Have the features been sorted into four groups?
- Is there a "not in this release" list?
- Are the admin panel, integrations and store work in scope?
- Is it clear how the first release's success will be measured?
How we do it at Globya
We write the scope together with you, starting from the user's day. The document clearly lists both what will be done and what won't be done in this release, and we base pricing and timeline on this written scope. Throughout the project we show working builds at short intervals; we explain how we work on our how we work page. In the projects we've run since 2000, what has worked best is starting small and growing together with the users.
Frequently asked questions
If we launch with an MVP, won't users find it lacking?
An app that does its core job completely isn't seen as lacking. Users are bothered by features that don't work, not by having few features.
Should we prepare the scope document ourselves?
No. It's enough to share your ideas, existing forms and process knowledge; we produce the document together.
When is the scope of the second release defined?
After the first release has been used by real users for a few weeks. Usage data and feedback are a far better guide than estimates made at a desk.
How do you set the price?
Once the written scope is clear. Pricing follows a written proposal after the discovery call. Describe your needs now in 3 minutes
The Globya assistant is online 24/7; it answers right away and passes your question to the team if needed.