The most expensive decision in most app projects is made before any code is written: what goes into the first version. Too much, and the launch slips by months while the budget runs out. Too little, and the product does not solve the problem well enough for anyone to use it.
"MVP", minimum viable product, has become a buzzword, but the idea behind it is practical. Launch the smallest version that does the core job well, learn from real users, and build the rest based on evidence rather than guesses.
Here is how I help clients get there.
Start from the core job
Every product has one job that matters more than everything else. For a booking app, it is "a customer books a service at a time that works, and the business can deliver it". For a field-service platform, it is "a job gets assigned, done and recorded". For an ordering app, it is "a customer orders and the order arrives".
Write that job in one sentence. Then, for every proposed feature, ask: does the core job fail without this?
- If yes, it is in.
- If it makes the core job noticeably better for most users, maybe.
- If not, it waits.
Map the journey, then cut
List the steps of the core job from start to finish, for each type of user. Then look at each step and ask what the simplest version is that still works.
Some examples of simpler versions:
- Accounts: phone number login instead of full profiles with photos and preferences.
- Payments: cash on delivery or bank transfer recorded by the admin before building online payments, if that is how customers pay today. See accepting payments.
- Notifications: a confirmation and a reminder, not a full notification centre.
- Search and filters: a short list and one or two filters, not a search engine.
- Reports: a simple export to a spreadsheet instead of a dashboard.
The simpler version is not worse; it is cheaper to build, faster to launch and easier to change once you know what users actually do.
Features that usually wait
These are the ones I most often suggest moving to "later":
- Loyalty programs and referral systems.
- In-app chat (a WhatsApp link often works at first).
- Multiple languages beyond the ones your current customers use. If your customers use Arabic and English, both are core; see bilingual apps.
- Social features: reviews, sharing, profiles.
- Advanced analytics dashboards.
- Automation of rare edge cases that staff can handle by hand.
Features that rarely wait
Some things feel optional but cause real trouble if left out:
- An admin panel that lets the business manage the core data without a developer. Keep it lean, but it must exist. See what an admin panel needs.
- Error tracking and basic monitoring, so you know when something breaks.
- Backups.
- Security basics: proper authentication, permissions checked on the server, HTTPS.
- Store requirements: privacy policy, account deletion where required, correct permissions text.
These are invisible to users, but skipping them creates problems that are expensive to fix after launch.
Design for change
The first version will change once real users touch it. A few choices make that easier:
- A clean data model that reflects how the business really works.
- A backend API that the app, admin and any future web app can share.
- Configuration in the admin rather than hardcoded: prices, services, time slots, texts.
- An automated deployment pipeline so updates are routine.
Building the foundation properly is not over-engineering. It is what lets you add the "later" list quickly.
A worked example
Take a cleaning company that wants a booking app, similar in shape to Pro Clean+, which offers booking with real time slots, prices and photo-based quotes in English or Arabic, plus packages and visit tracking.
A first version could focus on:
- Choose a service and see the price.
- Pick from real available slots.
- Confirm with address and notes.
- Get a confirmation and a reminder.
- Admin: manage services, prices, availability and bookings.
Photo-based quotes, packages and visit tracking are valuable, but each one could be the second or third release, built once bookings are flowing and the team knows what customers ask for most. Whether to include them at launch depends on the business; the point is to decide deliberately.
How to decide with limited information
You will not know everything before launch. A few ways to reduce guessing:
- Talk to five real customers about how they do the task today.
- Look at your own data: messages, calls, spreadsheets. What do people ask for most?
- Watch staff do the current process for a day.
- Prototype the key screens and show them to a few users before building.
Planning beyond launch
Scoping the first version is also about planning the second:
- Keep the "later" list, ranked.
- Decide what you will measure after launch: bookings completed, drop-off points, repeat use.
- Plan a first update a few weeks after launch to fix what users find.
- Budget for maintenance. See app maintenance after launch.
Talking about scope with your developer
A good developer will push back on scope, and that is a sign they care about your launch. When they suggest moving a feature to later, ask what it would cost to add after launch compared to now. Sometimes the answer is "the same", which makes waiting easy. Sometimes a foundation decision, such as supporting several branches or several languages, is much cheaper to make at the start, even if the feature itself comes later. Those are the conversations worth having before the first line of code.
Signs your scope is too big
- The launch date keeps moving.
- Nobody can describe the first version in two sentences.
- Most features are justified by "competitors have it".
- The admin side has more screens than the user app, for features nobody has asked for.
Signs your scope is too small
- The core job cannot be completed without staff stepping in every time.
- Users would need another tool to finish the task.
- The product looks like a demo rather than something people can rely on.
The right first version sits between those two: small, complete and solid. It does one job end to end, it is reliable enough that customers trust it, and it is built so the next release is easy.
If you are planning an app and want help drawing the line, start with how to write a brief, look at my work, and get in touch.