Key answer: In 2026 a mobile app costs from around €15,000 (a simple MVP with a few screens and login) to over €100,000 for a mature product. A typical larger app with user accounts, payments and sync costs €30,000–100,000. Price is driven mainly by the number of platforms, MVP scope, the back-end and design. Cross-platform technology (React Native, Flutter) cuts build and maintenance costs by 30–40%.
Table of contents
The short answer
In 2026 a mobile app costs from around €15,000 for a simple MVP to over €100,000 for a mature product with user accounts, payments and its own server side. A typical larger app sits in the €30,000–100,000 range. That spread isn't arbitrary: "a mobile app" describes both a simple product catalogue and a platform serving thousands of users a day. Below we break mobile app development cost into its components, so as a product owner you know exactly what you're paying for.
What drives the price of a mobile app?
Number of platforms: for most products we recommend cross-platform technology (React Native, Flutter). One codebase runs on both iOS and Android, cutting build and maintenance costs by 30–40% versus two separate native apps. Fully native development makes sense for hardware-intensive products: AR, advanced graphics or specific system APIs. If a quote assumes two native teams, ask why.
MVP scope: the biggest budget variable. Every screen, user role and integration is real weeks of work. A sensibly trimmed MVP starts from a hypothesis to verify, not a wish list – we've described how to scope one in our post on planning an MVP.
Back-end and integrations: most apps need a server – user accounts, a database, push notifications, an API – plus an admin panel. For simple products a ready-made back-end service keeps costs down; a custom server with integrations (payments, company systems, maps) raises the budget in steps.
Design: designing for a small screen is its own discipline. A clickable prototype tested with users before a line of code exists costs days of work, yet catches mistakes that would cost weeks to fix in a finished product.
App Store and Google Play publishing: preparing the app for both stores' requirements, store graphics, search-optimised listings (ASO) and the review process. Plus the fixed fees: an Apple Developer account is $99 a year, a Google Play account $25 one-off.
How much does an app cost by complexity?
€15,000–30,000 – a simple MVP. A few screens, login, one key feature, built cross-platform on a ready-made back-end service. Enough to test the idea with real users; such a project typically takes 3–5 months from workshop to store release.
€30,000–100,000 – a larger app. User accounts, payments, data sync, a custom back-end with an admin panel, polished design with animations. This is where most commercial business apps sit: from loyalty apps to field tools for service teams.
Above €100,000 – a mature product (indicative range). Multiple user roles, integrations with company systems, high security requirements, continuous data-driven development. At this level you're no longer buying "an app" – you're funding a product team, so the budget conversation is about monthly cost rather than a single figure.
What costs await you after launch?
An app differs from a website in that you can't simply leave it alone. Apple and Google release new system versions every year and change their store requirements along the way; without periodic updates the product starts breaking on new devices. Add servers (roughly €50 to €500+ monthly depending on user numbers – indicative), stability monitoring and ongoing fixes. For an actively used app, a realistic maintenance budget is roughly 10–20% of the build cost per year (indicative). Plan for it from the start – an unmaintained app loses store ratings faster than it earned them.
How do you lower the budget sensibly?
Start with an MVP, not the full vision. The product core is usually 20–30% of the original feature list, and it's the core that verifies whether the idea works. Build the rest once the data says it's worth it.
Choose cross-platform unless you have a hard reason not to. A 30–40% saving on build and maintenance, at a quality users won't tell apart from native.
Check whether you need an app at all. Sometimes a PWA – a progressive web app – delivers the same value at a fraction of the cost: no store review, one codebase for every device. We advise on this honestly, even when it means a smaller project for us.
Don't cut core quality. A slow, buggy app tests your users' patience, not your business hypothesis. Cut features, not quality.
How do you read software house quotes?
Compare scopes, not totals. Ask every bidder to itemise: cross-platform or native and why, does the quote include the back-end and admin panel, what about UX design and prototype testing, who handles store publishing, what does maintenance cost after launch. Two quotes "for an app" differing threefold usually describe two different products.
Red flags: a price given without a conversation about your users, no named technology, the back-end "out of scope" with no explanation, silence about maintenance costs and copyright transfer.
Where to start?
With a conversation about the problem, not the features. We start app projects with a product workshop: you leave it with a hypothesis, an MVP scope and a realistic budget – plus the decision whether this should be an app at all, or whether a PWA will do. See how we build mobile apps, or simply tell us about your idea and we'll work the numbers out together.