Buying Software
What an App MVP Actually Includes
The first version of an app should contain one core flow, built end to end, and tests on the paths where a failure costs you money or trust. It should leave out almost everything else, including several things that will feel essential on the day you commission it.
That is not a budget compromise. A narrow first version is the quickest way to find out whether the app does the job you bought it for, while changing it is still cheap. What follows is what goes in, what stays out, and what the stores will check before anyone can download it.
What should the first version of an app actually contain?
One workflow that works from the first tap to the last, used by real people with real data. "Minimum" refers to the number of things the app does, not to how finished each of them is.
In practice that means a person can sign in, do the one job the app exists for, and see the result, with nothing in the middle held together by a developer doing something by hand. Take a hypothetical renovation firm whose site supervisors photograph defects on site. The core flow might be: supervisor logs a defect with a photo, the office sees it, someone marks it fixed. That is a complete loop. A dashboard of defect trends is not part of it.
If the flow only works when someone behind the scenes fixes records manually, it is a demonstration, not a first version. The test is simple: could a person who was not involved in the build use it unaided?
How do you choose the one core flow?
Choose the flow that, if it worked and nothing else did, would still justify the project. Write it as a start point and an end point, the same way you would when scoping any software project before you pay.
Two checks help. First, can you state the finished result in one sentence about your business rather than about the software? "Every defect has an owner and a status the office can see" qualifies. "A defect management module" does not. Second, does the flow touch only data that can actually be reached? If it depends on a system that offers no export or integration, that dependency can decide the price, as covered in what moves the price of a custom build.
If you find yourself unable to choose between three flows, that is useful information. It usually means the pain is spread thin, and the better first step is a conversation with your own team, not a build.
What does "tests on critical paths" mean?
It means automated checks on the few places where a bug would do real damage, instead of an attempt to test everything. Which paths those are depends on the app, but they tend to be the same kinds of places.
- Sign-in and permissions: the wrong person seeing the wrong record.
- Anything involving money: totals, rates, payments, quotations.
- Anything that writes or deletes data: saving, editing, removing.
- The core flow itself: start to finish, so that a later change cannot quietly break it.
You do not need to read the tests. You do need to know they exist and what they cover, because they are what lets the second version change quickly without breaking the first. Ask which paths are covered and ask to see them run. An answer of "we test it by hand before each release" is an answer worth noting.
Which features are always deferred?
Several, and they recur across almost every first version. Deferring them is not a loss, because each one is much easier to specify after real people have used the core flow.
- Admin dashboards and analytics. You do not yet know which questions you will ask.
- Several user roles. Start with the minimum needed to keep the wrong person out.
- Notifications beyond the essential one. Each channel adds settings, edge cases and things that can fail.
- Offline mode. Valuable in some trades, but it multiplies the work on data conflicts. Add it deliberately, not by default.
- Integrations with other systems. Unless the core flow cannot work without one.
- Payments inside the app, when the business can collect the money the way it does today.
- Customisation and settings screens. Defaults chosen by someone who understands the business are enough at first.
The pattern is that each deferred item answers a question the first version will answer for you. Keep a written list of them. It becomes the backlog for the next phase, and it stops the same idea being re-argued every week.
What do the app stores check before a first version goes live?
Both stores have requirements that a first version has to meet, and it is cheaper to know them before the build than after a rejection.
Apple's App Review Guidelines say submissions should be final versions with all necessary metadata, with placeholder text and empty websites removed, and that apps which crash or show obvious technical problems will be rejected. If the app has a login, you need to supply demo account details and keep the back end running for the reviewer. The same guidelines say an app should offer more than a repackaged website, and that every app must link to a privacy policy that explains what data it collects. If the app lets people create accounts, it must also offer account deletion within the app. Distributing on the App Store also requires membership of Apple's developer programme, as described on Apple's membership comparison page.
On Google Play, a personal developer account created after 13 November 2023 has to run a closed test with at least 12 testers opted in for 14 consecutive days before it can apply for production access, according to Google's Play Console Help page. That is a calendar constraint worth planning around if the app will be published under a personal account. Check that page for the current requirements.
None of this changes what goes into the app. It changes the timetable, and it is a reason to keep the first version small enough to be finished, tested and submitted in good time.
How does this map to a fixed-scope package?
Our App MVP package is built around exactly this shape: a scoping workshop, one core flow built end to end, tests on critical paths, and store submission or deployment, at S$8,800 over 6 to 8 weeks, with weekly demos and two revision rounds per demo cycle. Anything past that scope is quoted before it is built. The point of listing it here is that a sensible MVP has a definable edge, whoever builds it.
When should you not build an MVP at all?
When a product that already exists does the job. If your core flow is something thousands of businesses do, such as invoicing, bookings or basic scheduling, buy the product and adapt to it. Custom software against off-the-shelf is a real decision, and the honest answer is often to buy.
Hold off too when the process is still changing. If the steps have shifted twice while you wrote them down, anything built now is a bet on a description that is already out of date. And if a web page or a form your team can use today would test the same idea, test it there first. An app is the expensive way to learn that nobody wanted the flow.
A first version succeeds when it makes the next decision obvious, including, sometimes, the decision to stop.
That shape is exactly what our App MVP package is: S$8,800 over six to eight weeks, starting with a scoping workshop, delivering one core flow end to end with tests on the critical paths, and ending in store submission or deployment. Weekly demos and two revision rounds per demo cycle mean you see it working long before it is finished, and you own the repository from day one.
If a recurring administrative task is costing your business more time than it should, we offer a 20-minute workflow conversation — one task, and an honest answer about whether automation is appropriate. Get in touch.
More from the blog
AI & Automation
Is It Safe to Put Customer Data Into AI Tools?
Pasting a customer's details into an AI tool is still using personal data under the PDPA. What the PDPC's generative AI guidelines say, what to keep out, and the controls a small business can set up in an afternoon.
Buying Software
Owning Your Code: Why Repository Ownership Matters
Owning your code means the repository, the accounts and the legal right all sit with you. What that looks like in practice, what goes wrong when a vendor holds it, and what to check before signing.