Founders often ask what an app costs before they have decided what the first version must do. The honest answer is that the price follows the scope, and building an MVP is mostly the work of cutting scope well. Here is what moves the number, the fees most estimates leave out, and how to plan a first version you can afford and actually learn from.
What an MVP is, and what it is not
A minimum viable product is the smallest version of your app that lets real users complete the one job you are betting on, so you can find out whether they want it. It is not a cheap copy of the full product, and it is not a clickable prototype. It has to be stable, quick and pleasant enough that users judge the idea, not the bugs.
The five things that set the cost
1. The number of user journeys
Count journeys, not screens: sign up, create a booking, pay, get notified, leave a review. Every journey brings screens, loading and error states, edge cases and tests. Most MVPs need two or three journeys done properly. Many budgets fail because they include eight done badly.
2. iOS, Android or both
Cross-platform frameworks such as React Native and Flutter build both apps from one code base, which usually costs far less than two separate native apps. Native development earns its price when the app leans heavily on device features or platform-specific performance. For most MVPs, cross-platform is the sensible default. Sometimes a web app that works well on phones is better still.
3. The back end
Anything that stores data, signs users in, takes payments or sends notifications needs a server side. Managed services such as Supabase or Firebase cover accounts, databases and file storage without building them from scratch, which keeps an MVP lean. A custom back end makes sense when the logic is the product.
4. Integrations
Payments, maps, calendars, messaging, AI models, a CRM. Every integration is quick to start and slow to finish: edge cases, failures, test accounts and the provider’s own review rules all take time.
5. Design depth
An MVP still needs real design: clear flows, readable screens and good empty and error states. It does not need a custom illustration system or elaborate animation. Spend design effort on the one journey that decides whether users come back.
Fees most estimates leave out
| Item | What to know |
|---|---|
| Apple Developer Program | Required to publish on the App Store; US$99 a year at the time of writing |
| Google Play developer account | A one-time US$25 registration fee at the time of writing |
| Store commission | Apple and Google take a share of digital purchases and subscriptions sold inside the app, usually 15% or 30% depending on the programme and your revenue |
| Hosting and services | Database, storage, email, push notifications and monitoring, billed monthly and growing with users |
| Store review | Costs time rather than money: a rejection and resubmission can move your launch date |
| Maintenance | New iOS and Android versions every year, library updates and the bug fixes that only real users uncover |
How to cut scope without cutting quality
- Pick one user and one job. If the app serves customers and staff, launch the customer side first and run the staff side from a simple admin panel.
- Replace features with manual work. Matching, approvals and onboarding can be done by a person behind the scenes until volume proves the need to automate them.
- Start with a web app if the idea does not need the camera, background location or app store discovery.
- Buy, do not build, accounts, payments, analytics and email.
- Write down what is out. A scope document that names what is not in version one protects the budget better than any contract clause.
Fixed price or time and materials
A fixed price works when the scope is written down in detail and unlikely to change. Time and materials works when you expect to learn and change direction, which is the whole point of an MVP. A common middle ground is a short discovery phase that produces the scope, the key screens and the estimate, followed by a build priced against that document.
Whichever you choose, ask who owns the code and the store accounts. The answer should be you.
What to bring to a first conversation
- The one job your first users must be able to do.
- Who those users are, and how you will reach the first hundred.
- Must-have integrations, such as payments or a calendar.
- Your deadline and the event behind it: a pitch, a pilot, a season.
- Your budget range. Sharing it is not a negotiating weakness; it lets a studio propose the scope that fits.
We build apps for startups and small businesses, and we run our own product, RingGenieHub, so we plan first versions with launch and running costs in mind. Read about our mobile app development and how we work with startups.