Plan your first app version around one job your users need done, and include only the features required to do that job reliably. Write every idea as a short user story, score each on value and effort, keep the essentials, and record what you're deliberately leaving out. That "not now" list protects your budget.
Feature planning is where app budgets are won or lost. A typical first version takes 10 to 20 weeks to build, and every feature you add either stretches that timeline or squeezes the time left for testing. This guide gives you a repeatable method you can run in a workshop with your team before you speak to developers. Our business guide to building a mobile app in 2026 covers the wider questions of cost and process.
What should version one actually achieve?
Version one exists to prove that real users will complete one core action, repeatedly. It isn't meant to be your full vision.
Write a single sentence in this format:
[User type] can [core action] so that [outcome], without [current pain].
For example: "Regular members can book a class in under 30 seconds so that they keep their spot, without phoning the front desk." Everything in version one should serve that sentence. If a feature doesn't, it waits.
If you struggle to write the sentence, pause. It may be a sign the app isn't the right first step; our comparison of whether you need a mobile app or a website can help you check.
Who are the users, and how many types do you really need?
List every type of person who will touch the system, then challenge each one. Each extra user type adds its own screens, permissions and testing, so it can add weeks to the build.
A class-booking app might have:
- Members who book and cancel classes
- Instructors who see their class lists
- Admins who manage the timetable, prices and members
Ask whether instructors need their own app screens in version one. Often a printed or emailed class list, or a simple view in the web admin panel, does the job for the first few months.
How do you capture every idea without arguing about it?
Hold a brain-dump session and write every idea as a user story, without judging it yet. A user story follows the pattern "As a [user], I want [action] so that [benefit]."
User stories keep the conversation on what people need rather than how screens look. "As a member, I want a reminder an hour before class so that I don't miss it" is clearer than "add notifications". Aim for 30 to 80 stories; it's normal to have far more than you'll build.
Group them into journeys: getting started, the core action, paying, managing your account and admin tasks. Gaps become obvious when you lay out a journey end to end.
How do you decide what makes the cut?
Score each story on two things, value to the user and effort to build, then apply a simple rule. Many teams also tag each item as Must, Should, Could or Won't for now (often called MoSCoW).
Use relative effort sizes (Small, Medium, Large) rather than guessing hours. Your developer can refine them later. Here is a worked example for the class-booking app.
| User story | Value to user | Effort | Decision for version one |
|---|---|---|---|
| Member signs up and logs in | Essential | Small | Must |
| Member sees the weekly timetable | Essential | Small | Must |
| Member books and cancels a class | Essential | Medium | Must |
| Member pays for a class pack by card | High | Medium | Must |
| Reminder notification before class | High | Small | Must |
| Admin edits timetable and capacity | Essential | Medium | Must |
| Waiting list with automatic promotion | Medium | Medium | Should, if time allows |
| Instructor app screens | Medium | Medium | Won't for now (use admin panel) |
| In-app chat with instructors | Low | Large | Won't for now |
| Social feed and badges | Low | Large | Won't for now |
| Apple Watch support | Low | Large | Won't for now |
The decision rules we'd suggest:
- Essential value, any effort: build it, but look for the simplest version.
- High value, small or medium effort: build it.
- Medium value, medium effort: a "should"; build only if the budget has room after testing time is protected.
- Low value or large effort with unclear value: move to the "not now" list.
If your must-have list alone can't fit a 10–20 week build, you haven't cut enough yet. Go back to the one-sentence goal and ask which items it truly depends on.
Which features do first-time app owners forget?
The unglamorous ones. They rarely come up in brainstorms but appear in every real app, and missing them causes delays and store rejections.
- Admin panel to manage content, users and orders without a developer
- Onboarding that explains the app in a few screens and asks for permissions at the right moment
- Password reset and email verification
- Account deletion from inside the app, which Apple and Google both expect when users can create accounts
- Empty states and error messages for no internet, no results or failed payments
- Notification settings so users control what they receive
- Privacy policy and terms linked in the app and the store listings
- Analytics events so you can see what people actually do after launch
- Basic support route, such as a contact form or email link
Add these to your list as Musts from the start. They usually take less effort than features users ask for, but leaving them out tends to surface late, when changes cost more.
How do you turn the list into something a developer can price?
Convert your Musts and Shoulds into a short scope document: screens, flows, rules and exclusions. A clear brief gets you comparable quotes and fewer surprises.
Include:
- The one-sentence goal and the user types
- User stories grouped by journey, marked Must or Should
- A rough screen list (sketches on paper are fine)
- Business rules, such as cancellation windows, refund policy or capacity limits
- Integrations, such as your payment provider, calendar or accounting software
- The "not now" list, written down and agreed
Our guide on how to write a software requirements document goes deeper into structure and examples. You don't need a 50-page specification; a clear ten pages beats a vague hundred.
How do you plan version two before version one ships?
Decide now what you'll measure, so version two is driven by evidence rather than opinions. Pick three or four signals tied to your goal sentence.
| What to measure | Why it matters | Example question it answers |
|---|---|---|
| Sign-up to first core action | Shows whether onboarding works | Do new members book within their first week? |
| Repeat use | Shows real value | What share of members book again within a month? |
| Feature usage | Shows what to improve or remove | Is anyone using the waiting list? |
| Support requests | Shows friction | What do people email about most? |
Review the "not now" list against this data after six to eight weeks of real use. Some ideas will become obvious priorities; others will quietly disappear because no one asks for them. Remember too that every feature you add brings ongoing upkeep, which is why annual app maintenance costs scale with scope.
Frequently asked questions
How many features should a first app version have?
There's no magic number, but most successful first versions focus on one core journey plus the essentials around it, such as login, payments and an admin panel. If you can't explain every feature's purpose in one sentence, the list is too long. Fit the scope to a 10–20 week build rather than a feature count.
Should version one include payments?
Include payments if charging is part of what you're testing, such as whether people will pay for class packs. If you're still testing whether people want the service at all, you can sometimes take payment offline or through a simple payment link first. Remember that digital goods sold in-app must use Apple's and Google's in-app purchase systems.
What if stakeholders insist their feature is essential?
Ask them to connect it to the one-sentence goal and to name what they'd remove to make room. Putting effort and value side by side in a table usually settles the debate without personal conflict. The "not now" list also reassures people that their idea is parked, not rejected.
Is it cheaper to build everything at once?
Rarely. Building everything up front means paying for features before you know whether anyone uses them. Releasing in stages lets you spend the later budget on what real users actually need.
Can a developer help prioritise features?
Yes, and a good one should. Developers can spot features that are cheap to add and others that are deceptively expensive, such as offline sync or real-time chat. A short paid discovery phase is often the most valuable money spent on a new app.
Turning your list into a plan
Bring your one-sentence goal and your rough story list, and a short scoping session can turn them into a costed, phased plan. See how we work and book a discovery call for a fixed-price quote.