What a Custom Mobile App Costs and What Drives That Price

"How much will our app cost?" is the first question I get. And the honest answer is: it depends on what it has to do. Not on how many screens it has. Two apps with the same screen count can differ fivefold in price, depending on what is under the hood.

This article is not a price list. It gives you a map of what drives the price, so you know what to ask about and where you can save without breaking your project.

Screen count does not set the price

A client typically describes an app through screens: "login, list, detail, profile, settings." That looks like five things. But a screen is just a window. The cost sits in what happens behind the window.

A list that pulls static data once a day is a few hours of work. A list that updates live, handles paging, offline state and synchronisation is a different discipline entirely. Same screen, a different order of magnitude in price. That is why the first question is never "how many screens", but "what does each one have to do".

What really drives the price

Four things move the budget the most. Run your brief through these four and you have 80% of the estimate.

Number of platforms

iOS, Android, or both? Each platform has its own publishing rules, its own signing certificates and its own quirks. A cross-platform framework (Flutter, .NET MAUI) shares most of the code, but testing, distribution and platform details multiply. A web version on top is another target. Two platforms are not double one, but they are certainly not free.

Backend

This is the most often underestimated item. The app is the shop window. The logic, data and rules live on the server. If you already have a backend with a usable API, the mobile part is relatively cheap. If the backend does not exist, you build it alongside the app — and that is often a bigger piece of work than the app itself. Authentication, database, permissions, API, hosting. The question "do you have a backend?" changes the estimate fundamentally.

Real-time features

Live data is expensive. When something in the app has to appear the moment it happens elsewhere — a vehicle's position on a map, a new message, an order status change — you need a persistent connection, outage handling and a single source of truth for state. That is a whole extra layer compared to an app that just pulls data occasionally. If pull-to-refresh is enough, you save. If you need second-by-second updates, plan for it.

Integrations with surrounding systems

Connecting to an ERP, accounting, a payment gateway, maps or an internal system is work you do not see in the UI, but it costs time. Every integration has its own format, its own errors and its own outages you have to handle. An app that lives on its own is cheaper than an app that has to talk to five other systems.

Flutter / .NET MAUI vs. native development

This choice decides the price and how fast you get the app out.

Native development means two separate codebases — Swift for iOS, Kotlin for Android. Two sets of team knowledge, two codebases to maintain, every bug fixed twice. It makes sense where the app lives or dies on performance or on a feature that cross-platform does not handle well — demanding graphics, deep hardware work.

Cross-platform (Flutter, .NET MAUI) means one codebase for both platforms. One team, one codebase, one fix. For most business apps — lists, forms, maps, real-time dashboards — it is the sensible choice: lower build and maintenance cost and a faster path to both platforms at once.

For .NET teams, .NET MAUI has the added advantage that the mobile part shares a language and a chunk of logic with the backend. Shared models and validation between server and app save time and errors. If you already have a .NET backend, that is a strong argument.

Honest gap: cross-platform is not free and universal. For 95% of business apps it is the right choice. For the one that needs extreme performance or an edge platform feature, you will handle it natively — and that is fine, you just want to know it up front, not halfway through the project.

Maintenance is part of the price, not an add-on

An app is not furniture you buy and own. It is more like a car — without servicing it stops.

Apple and Google change store rules, required SDK versions and target APIs every year. Certificates expire. Operating systems move on. An app left untouched for a year often stops building at all — not because of a bug, but because the ground shifted under it. The annual maintenance cost is a real item, better planned up front than handled as a crisis when the app gets pulled from the store.

What maintenance covers: keeping compatibility with new system versions, security updates to libraries, fixing reported bugs and renewing certificates. It is not new functionality — it is keeping what you have running.

What a realistic scope looks like

A mobile app as part of a larger platform can be delivered in months, not years — if the project has a clear brief and the backend is handled in parallel, not after the fact.

For a fleet manager we built a platform with a mobile app and a web part in roughly 4 months. The app works with live data from about 50 vehicles, and the whole platform is around 128,000 lines of code. It is not an app you assemble from a template — it has a backend, a real-time layer and integrations. And it still took four months, because the scope was clear from the start and was not built three times.

That is the point: price and time are decided most by how well the brief is thought through up front. The most expensive app is the one you build three times, because the scope kept surfacing along the way.

FAQ

How much does a custom mobile app cost to build?

The price is not driven by the number of screens, but by the backend, real-time features, external integrations and the number of platforms. A simple app on top of an existing API is far cheaper than an app with its own backend, live data and an ERP connection. Without a brief, no number is honest. You get a meaningful estimate after an hour over a list of functions.

Is Flutter cheaper, or native development for iOS and Android separately?

A cross-platform framework like Flutter or .NET MAUI is usually cheaper, because one codebase ships to both iOS and Android. Native development makes sense where the app lives or dies on a specific platform feature. For most business apps, a single cross-platform codebase is the sensible choice.

How much does maintaining a mobile app cost after launch?

Maintenance is not optional. Apple and Google change their rules and SDKs every year, certificates expire and operating systems move on. The annual maintenance cost typically runs from a few to the lower tens of percent of the build cost. An unmaintained app stops building sooner than you expect.

Want an estimate for your project?

We build custom mobile apps with backend, real-time layer and integrations — in .NET MAUI and Flutter. Instead of a price list, we offer an hour over your brief, which you leave with a realistic scope and estimate, not a number shot into the dark. Get in touch — we will go through what the app has to do and tell you what drives the price in your case.