Picture a founder with an app for booking dog groomers. The first specification runs to forty screens: customers, groomers, salon managers and an admin role; a loyalty programme; three payment methods; a chat; reports for salon owners; settings for every notification. The budget covers perhaps half of it. The usual answer is to remove features from the end of the list until the estimate fits.
That approach saves money in the wrong places. The end of a feature list is where the invisible work tends to sit, because nobody writes "error reporting" or "a way to fix a wrong booking" next to "loyalty programme". So the visible features survive, the plumbing gets cut, and the first weeks after launch are spent firefighting instead of learning.
A better way is to sort the list into two piles. One pile holds features that are expensive to build now and cheap to add later. The other holds things that are cheap to build now and painful to add once real users and real data exist. The first pile is where you cut. The second you protect.
1. Cut: every role beyond the two you need
Most products have one person who uses it and one person who serves them. In the grooming app, that is the customer and the groomer. Salon managers, regional managers and fine-grained permissions can wait. Each extra role multiplies the screens, the test cases and the questions about who may see what.
If a manager needs to see something in the first months, a weekly export or a read-only view built on the same screens is usually enough. When you add roles later, you will know which permissions people actually asked for, rather than the ones someone imagined in a workshop.
2. Cut: settings and preferences
Settings feel cheap, since each one is just a switch. In practice every switch doubles the paths through the code. Ship sensible defaults instead, and keep a short note of the settings people request. If three customers ask to turn off reminder messages, that switch has earned its place. If nobody asks, you have saved the work for good.
3. Cut: automations a person can run by hand for now
Version one does not need an automatic refund flow if refunds happen twice a month. It does not need a sync with the salon's accounting tool if someone can copy five invoices on a Friday. Manual steps are slow, but they show you exactly how the process works before you encode it. Automate a task once it happens often enough that doing it by hand costs real time, and once its rules have stopped changing.
4. Cut: rare paths, but write them down
Gift cards, group bookings, cancellations within the last hour. Real products have dozens of these cases. For version one, decide what happens in each one, even if the answer is "support handles it by phone", and write that decision down. A rare path that has a written answer is a deliberate gap. One that has no answer turns into a bug report the first time it happens.
5. Keep: a way to see what went wrong
Users rarely report errors. They close the app, try again later or quietly leave. Without crash reporting on mobile and error logging on the server, you learn about problems from reviews, if at all. Setting this up during the first weeks of development takes a day or two. Adding it after launch means guessing which of last month's complaints were real.
Keep the logs useful rather than large: the screen or endpoint, the app version, a user identifier you can look up, and the error itself. That is usually enough to reproduce a problem.
6. Keep: a way to fix a user's data without touching the database
Something will go wrong with a booking in the first week: a double charge, a wrong time, a groomer assigned twice. If the only way to correct it is for a developer to write a query against production, every small support request becomes an engineering task, and a risky one.
The answer does not need to be a polished admin panel. A plain internal page that lets a trusted person search for a customer, see their bookings and change or cancel one is enough. It also records who changed what, which you will want later.
7. Keep: account recovery and the emails that carry it
Password reset, email verification and booking confirmations look like small features. They depend on something easy to forget: email that actually arrives. Sending from a properly configured domain, with the records that mailbox providers check, decides whether these messages land in the inbox or in spam. A customer who cannot get back into their account on the first day is unlikely to try a second time.
If the app lets people create an account, also plan how they delete it. Apple's App Store requires apps that support account creation to offer account deletion inside the app, and privacy laws such as GDPR and KVKK give people the right to ask for their data to be removed. Building this at the start is a small task; adding it to a live system means finding every table that holds a customer's data.
8. Keep: a safe way to ship the next version
Version one is never the last, and on mobile you do not control when people update. Some users will run your first build for months. Two decisions made early save a great deal of trouble: version the API so that older app builds keep working while you change things, and include a simple check that can tell an outdated app to update when a change truly cannot stay compatible.
On the server side, the equivalent is being able to deploy a fix in minutes and roll it back just as quickly. If a release takes a day of manual steps, small fixes wait, and small problems grow.
A quick test for any feature
When you are unsure which pile something belongs in, ask two questions. If we leave it out, can a person cover the gap by hand for three months? And if we add it later, will we have to touch existing data or existing users' apps? A feature that passes the first and fails the second can wait. A piece of plumbing that fails the first or passes the second belongs in version one.
In short
Trim the parts of a first release that users can see but rarely need: extra roles, settings, automations and rare paths, each with a written fallback. Protect the parts they cannot see but will feel: error reporting, a safe way to correct data, account recovery and deletion, and a way to ship the next version. The first pile is cheaper to add later; the second only gets more expensive.
When we build MVPs, we agree on both piles before development starts, so the budget goes to the core flow and to the plumbing that keeps it running after launch.
Planning a project like this?
Plan it in 10 steps