What a mobile app really costs in 2026

Nobody publishes app prices, so every conversation starts from zero and half of them end in an awkward silence. This article puts our own 2026 numbers on the table and explains what moves them.

The ranges come from delivered projects. They assume both platforms, a real backend, and someone maintaining the thing after launch.

The ranges

For a team of 10–200 employees, one codebase covering iOS and Android:

• Internal tool — one role, 6–10 screens, works offline, syncs with your ERP: 8,000–18,000 EUR, 6–10 weeks.
• Field or warehouse app — scanning, photos, signatures, offline queue, several roles: 18,000–40,000 EUR, 10–16 weeks.
• Customer-facing app — accounts, catalogue, payments, push, both stores, analytics: 35,000–80,000 EUR, 4–6 months.
• Platform — multi-tenant, back office, integrations with three or more systems: 80,000 EUR and up, delivered in stages over 6–12 months.

If your project sits between two rows, it costs the higher one. It always does.

What actually drives the number

The backend, not the screens. Clients estimate apps by counting screens. We estimate them by counting the things the app has to agree with: your ERP, a payment provider, a courier, a login system. Each integration is a week that has nothing to do with the interface.

Offline. “It should work without signal” is one sentence in a brief and three weeks of work. You need a local database, a sync queue, and a conflict rule for when two people edited the same record on different phones. Ask for it only if the app genuinely goes where the signal does not.

Roles and permissions. One user type is simple. Three user types with different screens, different data and an admin who can impersonate them is a different project.

Design. Using a system design language costs nothing extra. A custom design with its own components and motion adds 3–6 weeks and needs a designer through the whole build, not just at the start.

One codebase or two

For almost every business app in this market, one Flutter codebase covering both platforms is the right answer. It cuts the build by roughly 30–40% against writing the app twice, and — more importantly — it halves what you pay to keep it alive for the next five years.

Native separates itself when you need something the platform gives you and nothing else does: heavy camera or sensor work, deep OS integration, or performance at a level games need. That is a real reason, and it is rarer than it sounds. “It should feel native” is not a reason; a Flutter app built properly does.

The costs that arrive after launch

This is where budgets break, because nobody puts them in the first estimate:

1. Store fees and accounts
   • Apple Developer: 99 USD a year. Google Play: 25 USD once.
   • Both need company verification, which takes days, not minutes.
2. Keeping up with the platforms
   • Apple and Google each ship a major OS version every year, and each raises the minimum SDK.
   • Budget 15–20% of the build cost per year just to keep the app in the stores and working.
3. Infrastructure
   • Backend hosting, push service, error tracking, storage: 50–400 EUR a month depending on volume.
4. The second wave of work
   • Every app that gets used generates a list of changes in the first three months. Plan for it instead of being surprised by it.

An app you build and abandon stops working within eighteen months. That is not a failure of the app; it is how the platforms work.

How to cut the number without cutting the app

Ship one role first. The warehouse app does not need the manager dashboard in version one. Ship for the people who use it hourly, learn from real use, then build the rest.

Cut offline if the signal is fine. Half the offline requirements we receive are for apps used inside a building with wifi.

Use the platform’s own components. Custom navigation and bespoke controls are the most expensive pixels you will ever buy.

Do not build a mobile version of your whole ERP. Pick the three things people actually do on their feet. Everything else belongs on a screen with a keyboard.

How to read an estimate

An honest estimate names its assumptions and its exclusions: which integrations, which roles, whether offline is in scope, who provides the design, and what happens after launch. A single number with no assumptions attached is not an estimate, it is a hope.

Ask for the price of the first release and the price of the first year of running it. If the second number is missing, the first one is incomplete.