In this article (15 sections)
There's a question that comes before "how much does an app cost", and answering it wrong is what makes so many mobile projects end up costing double: do you need an app, or do you need your system to work well on a phone?
They're not the same thing, they don't cost the same and they don't even look alike. This piece separates the two, gives real price ranges for building with a nearshore team in 2026, and covers the costs that show up after launch and that almost nobody budgets for.
First: do you actually need an app?
A native app —the one people download from Google Play or the App Store— is justified when you need at least one of these:
- Working offline. An operator in a warehouse with no signal, a driver in a dead zone, a rep out in the field. If the work stops when there's no internet, you need an app.
- Heavy use of the phone's hardware. Camera for scanning codes all day, background GPS, NFC reader, bluetooth with a device.
- Reliable push notifications. Web notifications exist but they're less reliable, especially on iOS.
- Daily, frequent use. If your user opens this fifteen times a day, the icon on the home screen is worth a lot.
If your case doesn't fall into any of those four, what you probably need is a web application built properly for a phone. It costs considerably less, it updates without going through any store, and it doesn't force anyone to install anything.
That first filter is the decision that saves the most money in the whole project.
The four technical options
Responsive web app
A web system that's comfortable to use from a phone browser. Nothing to install, not in the stores, doesn't work offline.
When: occasional use, no hardware, no offline. Customer portals, lookups, approvals, occasional data entry.
PWA (Progressive Web App)
A website with extra capabilities: it can be "installed" on the home screen, it partly works offline and it can send notifications. It doesn't go through the stores.
When: you want something close to an app without the cost or the friction of the stores. It works well on Android; on iOS it has real limitations that are worth checking against your specific case before committing.
Cross-platform (React Native or Flutter)
One codebase that produces two apps, one for iOS and one for Android. It's the default option today for the vast majority of projects.
When: you need a real app on both platforms. It covers 90% of business cases at a quality the end user can't tell apart from a native app.
Fully native (Swift and Kotlin)
Two applications, two codebases, two teams.
When: demanding graphics performance, heavy use of very new operating system APIs, or very specific security requirements. For a business management app it's almost never justified: you're paying for two builds to get a benefit your user won't notice.
The numbers
Reference ranges for building with a nearshore team in mid-2026, for the initial development.
- Responsive web app — USD 4,000 to 10,000. A web system designed for the phone, with the screens your operation needs.
- PWA — USD 6,000 to 15,000. The above plus the work for offline operation, installation and notifications.
- Contained cross-platform app — USD 10,000 to 20,000. An app with one user role, five to eight screens, sync with your system, login, notifications. The typical case of an internal app for a field team.
- Full cross-platform app — USD 20,000 to 45,000. Several roles, offline operation with conflict resolution, payments, maps, heavy camera or scanner use, web admin panel included.
- Fully native — add 60% to 80% on top of the cross-platform equivalent, because you're building and maintaining everything twice.
One thing that tends to surprise people: in a business app, the backend and the admin panel are usually more work than the app itself. The app is the visible tip; behind it there's an API, permissions, sync and a place where administrators see and configure everything. If an app quote doesn't mention the backend, ask where it is.
What's almost never in the quote
The developer accounts
- Google Play: one-time payment of USD 25.
- Apple Developer Program: USD 99 a year, every year. If you stop paying it, your app leaves the store.
Put them in your company's name, not the vendor's. It's the mobile equivalent of having the domain in your name, and recovering an account held by a third party is a slow process and sometimes an impossible one.
Apple's review
Apple reviews every version by hand. It can take from a day to a week and it can reject you. The most common rejection reasons for business apps are avoidable if you know them in advance: no privacy policy, apps that are just a wrapper around a website, payment features that route around Apple's system, or test accounts the reviewer can't use.
Budget two weeks between "the app is ready" and "the app is published" for the first launch.
The mandatory maintenance
This is what makes an app different from a web system, and it's the cost people underestimate most. Apple and Google update their operating systems every year and require apps to move to the new versions of their tooling to stay publishable.
Translation: an app needs maintenance even if you never add a single feature. Budget USD 1,500 to 4,000 a year just to keep it working and keep it in the stores.
An app abandoned for two years isn't an old app: it's an app that stopped being available.
Android fragmentation
If your app is going to be used by operators, drivers or field reps, the phones won't be the latest models. They'll be low-end devices with old Android versions, little memory and small screens. Decide from the start which version you'll support and ask for testing on a real device in that range, not just on the emulator.
Five decisions that set the cost
1. Does it work offline? This is the most expensive decision of all. Working offline isn't storing data locally: it's resolving what happens when two people changed the same thing while disconnected. It can add 30% to 50% to the project. Ask yourself whether you really need it or whether showing a "no signal" message is enough.
2. How many user roles? Each role is a set of screens and permissions.
3. Are there payments inside the app? If you sell digital goods or services, Apple requires its payment system and takes a cut. If you sell physical goods or real-world services, you can use your own gateway. The distinction matters and it's worth settling before you design anything.
4. Do you need both platforms from day one? If your app is internal and you choose the devices, start with Android: it's cheaper, faster to publish, and work fleets tend to be Android.
5. Do you already have a system to connect to? If the backend has to be built too, the project is substantially bigger.
How to shrink the first project without regretting it
The strategy that works best is to start with a web app for the phone and turn it into an app once usage justifies it.
In practice: you build the web system with the screens designed for the phone, you get it running in weeks and at a much lower cost. Your team uses it. That's where you find out which three screens actually get used all day and what really needs to work without signal. And only then do you build an app focused on exactly that.
It's cheaper, it's faster and —most importantly— the app that comes out is different from and better than the one you would have specified without that experience.
Before you ask for quotes
Write down three things:
- Who's going to use it and in what physical setting. An office is not the same as a warehouse with no signal or the street under the sun.
- The three most frequent actions. What the user will do fifteen times a day. The rest is secondary.
- Whether the work can wait for a connection. It's the question that moves the budget most.
With those three answers, the quotes you get will be comparable to each other. Without them, every vendor will quote a different app and you won't be able to choose.