App Development Cost: Factors, Technologies and Running Costs

What is the app development cost for a business? As an indicative order of magnitude, it ranges from a few thousand euros for a simple web app built on systems you already have, up to several tens of thousands for a native or cross-platform app with its own backend, ERP integrations and offline features. Four choices set the price: which platforms it has to run on, with which technology, how many systems it has to connect and how much care the user experience needs.

Below you'll find the cost factors one by one, a comparison of native, cross-platform and progressive web apps, the running costs many quotes leave out, and a real case. That way, when you ask for a quote, you can read what's in it and what's missing.

How much does an app cost: orders of magnitude

There is no price list, and be wary of anyone who offers you one before understanding what the app has to do. To help you get your bearings, these are indicative orders of magnitude for SME projects, to be taken as a playing field and not as a price:

The range within each band is wide for a simple reason: two apps with the same list of screens can have very different logic underneath. An app that shows a customer's orders costs little. An app that lets the customer change them, recalculates prices based on the customer's price list and sends them back to the ERP costs much more, even if the screens are the same.

The factors that set the price of an app

Platforms: iOS, Android, web

The first question is where the app has to run. An app for your company's technicians, who all use the same Android phone model supplied by the company, can stick to one platform. An app for customers has to work on iPhone and Android, and often in the browser too for people working at a computer. Each additional platform adds development, testing and publishing.

Technology: native, cross-platform or PWA

This is the choice that moves the quote the most, and we cover it in the next section.

Backend and integrations

The app is the part you see. Behind it there is almost always a backend: the server that stores the data, manages users, sends notifications and talks to other software. If the backend already exists (because you have an ERP with documented APIs), the app relies on it and the cost goes down. If it has to be built from scratch, it is often the heaviest item in the project.

Every integration is a small project in its own right: ERP, CRM, e-commerce, invoicing system, warehouse. With modern software that exposes APIs the connection is straightforward; with an old ERP that only exports files it takes more hours and more testing.

Design and usability

An internal app used by ten warehouse staff can have a plain interface, as long as it's fast and has big buttons. An app for customers needs more design work: flow analysis, prototypes, testing with real users, attention to visual detail. Design is the item most often cut in low quotes, and it's the one that decides whether the app gets used or abandoned after a week.

Features that weigh more than they seem

Some features look small and aren't. Offline operation, for example: a technician in a boiler room with no signal must be able to fill in the job report and sync it when the connection returns, without losing data or creating duplicates. Similar items are real-time sync between several users, on-screen signatures with documentary value, payments, continuous geolocation, and managing different roles and permissions.

Publishing on the stores

Publishing on the App Store and Google Play requires developer accounts, store listings with text and images, privacy notices, and passing Apple's and Google's review, which can reject an app and ask for changes. You need to allow time to prepare all of this, on top of the account fees you'll find further down.

Native app, cross-platform or progressive web app

These are the three possible routes. None is better in absolute terms: it depends on who will use the app and what it has to do.

Native app

Two separate apps are developed, one for iOS (in Swift) and one for Android (in Kotlin). You get maximum control over performance and phone features, but you pay for two developments and two maintenance tracks. For most business apps of an SME this is an expense that can't be justified. It makes sense when you need particular performance or heavy use of the hardware: video processing, augmented reality, low-level Bluetooth communication with devices.

Cross-platform app

With frameworks such as Flutter or React Native you write a single codebase that produces the app for both iOS and Android. You save a substantial part of development compared with two native apps, and there's only one codebase to maintain. For management apps, apps for sales agents, apps for technicians and customer apps, it's the option we propose most often, because it gives access to camera, notifications, GPS and offline operation with a single project.

Progressive web app

A progressive web app (PWA) is a web application that opens in the browser but can be installed on the phone's Home Screen and opened full-screen like an app. It doesn't go through the stores: you update it on the server and every user gets the new version immediately. Since iOS and iPadOS 16.4, web apps added to the Home Screen can also receive push notifications, as announced by the WebKit team.

A PWA costs less, because it's a single web application that runs everywhere. It has limits: access to some phone features is more restricted than for an app installed from the stores, on iPhone the user has to add it to the Home Screen from Safari's Share menu, and for a consumer audience its absence from the store can affect trust.

For an internal tool or a private area for your B2B customers, a PWA is often the right choice and saves a good deal of money. If instead your app has to be found on the App Store by people who don't know you, you need a proper store app.

Running costs after launch

The development quote is only the first item. An app has costs that continue as long as you use it, and that's where surprises come from.

Store accounts

To publish on the App Store you need to enrol in the Apple Developer Program, which costs USD 99 per membership year according to Apple's official page (the price in local currency may vary by region). To enrol a company, Apple also requires the organisation's D-U-N-S number and a working website on the company domain: if you don't have a D-U-N-S number, request it in good time. For Google Play, registering the developer account involves a one-time fee of USD 25, as stated in the Play Console guide. These are small sums, but the accounts should be in your company's name, not the developer's.

Hosting and external services

Servers, database, backups, storage of photos and documents, sending notifications, emails or text messages. It depends heavily on the number of users and the amount of data: for a business app with a few dozen users it's a modest item, for a consumer app with thousands of active users it grows with usage.

Maintenance and updates

Every year Apple and Google release new versions of their operating systems, and Google Play periodically requires apps to be updated to recent Android versions to keep distributing them. The libraries used by the app receive security updates. An app nobody updates for two years starts causing problems, and at some point stops working on new phones. Maintenance is usually paid as an annual fee or a block of hours: get it in writing what it includes and what is billed separately.

New features

After launch, user requests arrive: an extra field, a report, a new integration. It's worth setting aside a budget for the first few months, because that's when the app adapts to real use.

What makes the quote go up or down

The cost goes down when:

• the backend or APIs already exist and the app only reads and writes them;
• the first version contains only the features genuinely needed from day one;
• decisions are made quickly by one person who knows the process;
• a PWA is enough for the intended use.

The cost goes up when:

• requirements change once development has started, especially business rules;
• the app has to work offline with a lot of data;
• there are several integrations, or integrations with software that exposes no APIs;
• several user types with different permissions are needed, for example office, technicians and customers;
• there are particular security or compliance constraints.

A mistake we see often: asking for a quote for "an app like our competitor's". That app has years of development behind it. It's better to start from the problem to solve and the three or four actions the user must be able to perform.

A real case: Dabe Connect

Dabe Service is an industrial and residential building services company with over 40 years of experience and dozens of technicians in the field. Before the project, scheduling ran on phone calls, emails and Excel sheets, and technicians filled in paper job reports to be handed in at the office, with documents that got lost, were illegible or arrived late.

For them we developed Dabe Connect, made up of three connected parts. A web management platform for the office, with records of customers, buildings and machinery, job scheduling and deadline alerts. A mobile app for technicians, Dabe Mobile Connect, from which they receive work orders, consult technical documentation, fill in the job report, attach photos and collect the customer's signature on screen, with real-time sync to the platform. And a customer area, from which customers see the history of jobs, download reports and open tickets.

Compared with the cost items above, it's a project in the top band: three interfaces, three user types with different permissions (office staff, technicians, customers), communications encrypted with TLS 1.3 and two-factor authentication for administrative access. The results reported in the case study: paper documentation for maintenance and installation jobs reduced by 100%, human transcription errors reduced by 95%, customer-perceived value up 70% thanks to the personal area. If digital job reports interest you, we cover them in the article on the app for field technicians.

How we keep costs under control

In our mobile app development projects we start with an analysis together with the people who will use the app: technicians, agents, customers, office. From there we define a first version with the features that matter, and we develop it in two-week sprints. At the end of each sprint the app can be installed in a staging environment, where your team tries it on their own phones and decides what to fix before moving on. That way the budget is spent on verified features, not on assumptions.

The source code is owned by the client, and the store accounts are in the company's name. If the app has to talk to an ERP, we first assess whether it's better to rely on the existing one or to build the management side too: for the costs of the latter there's a guide on how much custom management software costs. If your idea concerns your sales network, the article on the app for sales agents may also be useful.

Selli is not the right choice for everything. For a game, a consumer app aiming for millions of downloads or a project that needs a full-time dedicated team for years, there are better-suited organisations. We work well on business apps that solve a specific operational problem.

Let's talk

If you're considering an app for your customers, your technicians or your sales network and want to understand which technology makes sense and what level of spending to expect, book a call with Selli. Together we'll look at what the app has to do, which systems it has to talk to and whether a PWA is enough, before we talk about a quote.