What does an app cost? Honest numbers after 20+ apps of our own

"What does an app cost?" is the most common question in our first conversations — and the internet answers it with ranges from €5,000 to €500,000. That's about as useful as "a vehicle costs between €500 and €500,000". We've been building apps since 2018 and run more than twenty of our own. Here's the answer we wish we'd had back then.

Why are the ranges on the internet useless? Because "app" describes everything — from a reference tool with three screens to a marketplace with a payment system and tens of thousands of users. Stretching one range across all of that says nothing. An honest answer has two parts: what actually drives the price — and which size class your project lands in.

The six cost drivers that actually matter

We often hear the question "How many screens does the app have?". It's the weakest cost indicator there is — an extra screen is an afternoon. These six things are not:

• Platforms. iOS, Android or both? Two separate native apps mean double the frontend development — for every feature, every bugfix, every update. More on that below.
• Backend. An app that runs on its own is a different job than one with accounts, sync and push notifications. The latter needs servers, a database, interfaces — and someone to operate all of it.
• Login and roles. Registration, password reset, roles and permissions, GDPR-compliant deletion: invisible in the mockup, one of the most expensive items in the code.
• Offline capability. Does the app have to work without signal? For RoadReview, yes — driving lessons happen on country roads, not on Wi-Fi. Offline means local data storage plus sync plus conflict resolution, and that easily doubles the effort in the data layer.
• Interfaces. DATEV, ERP, calendar, payment provider — what decides the price is not whether the connection is possible, but how well the respective API is documented.
• Store review and compliance. Apple and Google review every app: privacy labels, permissions, in-app purchase rules, test accounts for the reviewer. Whoever knows the process plans for it; whoever doesn't loses weeks right before launch.

And what rarely drives the price: the things that get discussed the longest. Colours, the app icon, the tenth screen. One more elaborate screen never moves a project into the next class — a forgotten interface or a belated "it has to work offline too" does so reliably. The expensive metres lie beneath the surface.

Three size classes with honest ranges

We calculate apps in the same three shoe sizes as all our projects. The ranges are deliberately wide because they're honest — where a project lands is decided by the six drivers above:

1. Tool app: €8,000–25,000 net. A focused tool without a large backend of its own: a capture app for field staff, a digital handbook, a companion to an existing system. One purpose, few roles, manageable data storage.
2. Lean MVP: €25,000–80,000 net. A real product in its first honest version: accounts, backend, push, both stores. The core function complete, the wish list deliberately cut. This is the most common size on our desk.
3. Full-grown product: from €80,000 net. Multiple user roles, payments, an admin console, ongoing development. What RoadReview is today grew over four years — nobody seriously builds something like that in one go, and whoever offers it as a first project is selling a bet.

An example of how drivers and classes interact: an app that lets technicians capture jobs on the go — photos, checklist, signature, handover to the office — sounds like a tool app. And it stays one, as long as it works online and docks onto a system with a clean API. Add offline capability for the underground car park and a second legacy system without documentation, and the same project moves into the MVP class. Not because someone raised the price — but because two drivers got flipped.

After the first conversation, a fixed-price sketch replaces the range with a concrete number — in writing, with assumptions. How that scoping works is on our app development page.

Why one codebase almost halves the bill

In 2021 we built ClickTestBuy — the appointment app for Covid test centres in the OWL region. Native, back then: once in Swift for iOS, once in Kotlin for Android. Every feature built twice, every bug fixed twice, every release tested twice. It worked because it had to happen fast — but the bill made the decision for next time on our behalf.

Since then we build business apps with Flutter from one codebase — RoadReview and LS-Athletics run in both stores that way. Does it halve the bill? Calculated honestly: it halves the frontend share. Backend, design, store release and project management stay the same. In total that saves roughly a third, depending on the project — enough to turn "unaffordable" into "doable". When Flutter is not the right choice — widgets, Watch, deep platform features — we've written up separately: Flutter or native?

The running costs after launch

After launch an app isn't finished, it's in operation. Four items belong in the budget from day one:

• Store fees. Apple Developer Program $99 per year, Google Play a one-time $25 — the smallest item, but without it the app is gone.
• Mandatory updates. New iOS and Android versions ship every year. Whoever does nothing for two years risks crashes on new devices — and Apple removes long-unmaintained apps from the store.
• Operations. Hosting, database, push services, monitoring, certificates. Unspectacular, monthly, unavoidable.
• Further development. The features real users rightly demand after four weeks. Whoever has no budget for that has a launch, but not a product.

As a rule of thumb we plan 10–15% of the build cost per year for maintenance and operations — for apps rather at the upper edge, because two operating systems move forward every year. More important than the exact percentage is that the line item exists from day one, in the budget and in people's heads. The most expensive apps we encounter are the ones untouched for two years: update backlog, outdated libraries and an expired certificate all come due at once — as one large, unpleasant lump instead of a plannable monthly routine.

Real savings levers

• Cut the MVP radically. The core function first, into real hands fast. Expanding is always possible — shrinking never is.
• One codebase instead of two. The biggest single lever when both stores are needed.
• Don't re-solve solved problems. Login, push, crash reporting are standard building blocks — we use Firebase services where they fit, for example, instead of sinking weeks into homegrown versions.
• Plan phase 2 after real users. Commission the second stage only once the first has been in the field. The priorities will change, guaranteed.

False savings levers

• The €15,000 provider for the €60,000 project. The money is missing somewhere — usually in tests, error handling and maintainability. You pay the difference later, with interest.
• A site builder for a real product. No-code tools are great for prototypes. For a product with its own requirements you hit a wall after months — and then rebuild anyway.
• Cutting design. This isn't about polish, it's about usability. The app nobody understands is the most expensive one — regardless of what it cost.
• Testing and review "later". A rejected store submission right before the promised launch costs more nerves and money than any week of testing beforehand.

And the most useful calculation here, too, isn't "What does the app cost?" but "What does it cost not to have it?" — per week, in working hours or lost orders. Whoever knows that number can put the ranges above into perspective. And whoever wants the concrete number for their project: a first conversation is enough, and the fixed-price sketch follows in writing. The ranges in this article are the start of that conversation — not the fine print at the end.