How to use it
- 01
Describe the app plainly
Write the one-line description as you would say it to a stranger. If it takes three lines, the idea is probably two apps, and the planner will show you where they divide.
- 02
Choose platforms and offline needs
These answers shape the technical approach before a single feature is discussed. Working fully without a connection, for instance, is a different project from tolerating a weak signal.
- 03
Sort every feature
Go down the list and give each line a level. When most things land in the first column, go through it again and move half of them, because a first version with everything is a full product.
- 04
Share the scope
Copy the document and give it to each team you ask for an estimate. Their questions about it will tell you a good deal about how carefully they read.
What a mobile app scope should settle
An estimate is only as good as the scope behind it. These are the decisions that move an app's cost and schedule the most, and the planner asks for each of them.
| Part | What it settles | Why it matters |
|---|---|---|
| The idea | What the app is and whose problem it solves | Keeps every later decision tied to one purpose |
| Platforms | Which devices, and how the app is distributed | Decides the technology and the store requirements |
| Offline behaviour | What works without a connection | Offline data and syncing are among the costliest features |
| Users | Roles and how they sign in | Each role adds screens, permissions and tests |
| First-version features | What ships first, what follows, what is out | The clearest lever on budget |
| Data and systems | Connections and sensitive information | Brings integration and privacy work into view |
| Launch | First users, timing and support | Shapes the release plan and what happens afterwards |
A worked example
A sailing club replacing a paper diary
Load the example to see a small club's booking app scoped in a few minutes. The club is invented, and its choices are typical of a sensible first version.
- What ships firstProfiles, booking, payments, notifications and an admin panel. Five features, each one needed for a member to book a boat and for the office to run the day.
- What waitsSearch, a content feed and analytics are marked later. They are useful, but nobody is prevented from sailing without them.
- The special featureA weather hold that cancels a day and credits every member. It appears nowhere on a standard list, and it is the feature the office will value most.
Children's data and payment details are both ticked, which tells a team to plan consent, privacy and payment handling from the start instead of discovering them at store review.
What this tool does not do
A scope is a starting point for a conversation with a development team. The planner does not try to be more than that.
- It does not produce a price or a schedule. An estimate needs a team to choose an approach first.
- It does not judge your idea. Whether people want the app is a question for research and a pilot.
- It does not cover design. Screens and flows come after the scope is agreed.
- It keeps nothing on a server. Your answers live in this browser until you remove them.
What to do with the finished document
Ask each team for an estimate of the first version only, with the later features listed separately. If you want our estimate, we answer scopes like this one with questions first and a proposal second. Send it through the contact page or book a 30-minute call and bring it along.
Common questions
How many features should a first version have?
As few as let a real user complete the main task from start to finish. For a booking app that might be signing in, booking, paying and being reminded. Everything else is easier to judge once people are using it. If your first column holds more than about half of the list, it is worth challenging each line once more.
Do I have to choose iPhone or Android first?
Not necessarily. Many business apps are built once for both platforms with shared code, which the planner allows for when you tick both. Choosing one first can still make sense for a pilot with a known group of users. Our comparison of native and cross-platform development explains when each approach fits.
Why does the planner ask about sensitive data?
Because it changes the work. Payment details, health information, children's data and location history each bring rules from app stores and from privacy law, and sometimes extra review before release. A team that knows about them at the start can design for them. Discovered late, they delay launches. Which rules apply to you is a matter for your legal adviser.
What is the difference between this and a requirements document?
A scope decides what is in and out of the first version. A requirements document then describes each included feature in enough detail to build and test it. The scope comes first and is much shorter. Our guide on writing a mobile app requirements document covers the next step.