If you’ve never shipped an app before, build an MVP first. If you have paying users and a clear next feature, skip the MVP. Everything between those two is judgment — and judgment costs money in the wrong direction is what burns the budget on first-time apps.
Here is how to decide.
When the MVP is the right move
- You haven’t validated the core hypothesis with real users. You think people will pay you for X. You have no proof. An MVP turns “I think” into “I know” in 2 to 4 weeks for around €15,000 — a third of the production budget and a quarter of the time.
- You’re spending someone else’s money. Investors and grant committees want validated metrics, not a feature list. An MVP gives you a real number to put in the next pitch deck.
- The market is moving and you can’t afford to wait three months. App stores change, competitors ship, the use case window closes. An MVP gets you something live before the window shuts.
- You’re not sure which platform matters more. An MVP forces you to pick iOS or Android first. The data from that one decides the second platform — instead of paying for both upfront when you might only need one.
When the MVP is the wrong move
- You already have paying users. Skip the MVP, build the v2 they’re asking for. Your validation is the credit-card statement.
- The product is the integration. If 80 % of the value comes from talking to SAP, Stripe, your existing ERP — an MVP that fakes that integration validates nothing useful. Build it properly or don’t build it.
- You have a contract that says “production-grade by date X”. SLA, GDPR audit, hospital procurement — none of these accept “this is just an MVP” as an answer. Go straight to production.
- Cost-of-running matters more than cost-of-building. Some businesses care that the backend stays up at 4 AM on a public holiday. An MVP backend isn’t built for that. A production backend is.
What an MVP actually is
A Minimum Viable Product is the smallest version of your idea that lets a real user accomplish the core job once, end-to-end. It is not a prototype, not a clickable mockup, not a “v0.1 with rough edges”. It is real software in real users’ hands.
What is in an MVP:
- The single core flow, built properly
- App Store / Play Store submission (real users live there)
- A backend that can hold the data and not lose it
- The 5 hardest legal touchpoints (privacy policy, login, payment receipt, deletion request, terms)
What is not in an MVP:
- Settings screens you might want later
- Multiple language support (start with one)
- Edge-case empty states for features that don’t exist yet
- A second platform “just in case”
What you trade away with an MVP
Be honest about this — an MVP isn’t free in real terms. You give up:
- Second-platform users for 3–6 months. If your audience is split 50/50 iOS/Android, an iOS MVP misses half the addressable market until you build the Android version.
- Some scalability headroom. The MVP backend will handle hundreds of users fine. It will need a refactor (paid for in the production build) before it handles tens of thousands.
- A bit of polish. Onboarding, animations, advanced search — these come in the production build. MVP users see the core path; advanced users see “coming soon”.
The MVP value isn’t in saving money permanently. It is in spending the right money in the right order — you find out what to build before you commit to the build.
How to decide in one paragraph
- If you can answer “Yes, this exact thing works and people pay for it” — skip the MVP, build the production app (€30k–60k, 3–4 months).
- If you can’t — start with an MVP (from €15k, 2–4 weeks) and use what you learn to scope the production build.
- If you’re not sure: that’s your answer. Build the MVP. The cost of being wrong with €15k of MVP is recoverable. The cost of being wrong with €60k of production app is not.
What happens next
Send a one-paragraph description of what you want, and you get back a written brief within 48 hours — including whether you should be doing an MVP or a production build, with a concrete price for each. Free, no commitment, on the contact page. The detailed price ranges for both options live on the pricing page, and the full cost breakdown for an app build is in the cost guide.