Five items determine the cost of a corporate mobile app: target platform (shared codebase vs native), offline capability, device hardware use (barcode, camera, location), back-end and integration load, store publishing and maintenance. Screen count is secondary to all of these. For field-team apps, offline synchronisation is typically the single largest cost driver.
- Cost is driven by platform choice, offline capability and integration depth — not screen count.
- A shared codebase reduces both initial cost and long-term maintenance in most enterprise scenarios.
- Offline capability is an architectural decision; adding it after the fact means rewriting the data layer.
- Back-end services and ERP integration typically account for close to half of total project work.
- Store accounts should be opened in the organisation's name, not the supplier's.
- OS version updates require annual compatibility work; the maintenance agreement must cover this explicitly.
The five cost drivers
The most common mistake when requesting a mobile app quote is comparing two proposals by total price. Two proposals covering the same number of screens can differ by a factor of two because of the items below.
- Platform choice — shared codebase or separate native builds for iOS and Android
- Offline capability — disconnected use and sync conflict resolution
- Device hardware — barcode/QR scanning, camera, location, signature, push notifications
- Back-end and integration — services the app talks to and ERP connectivity
- Publishing and maintenance — store processes, OS compatibility, version management
Shared codebase vs native
For the large majority of enterprise projects, a shared codebase is the right answer. Targeting two platforms with a single development team measurably reduces both the initial cost and the long-term maintenance burden, and also reduces the risk of behavioural divergence between platforms.
Native development is meaningful for apps that operate at the limits of device hardware: continuous camera stream processing, intensive background location tracking, or apps that talk to a proprietary device driver. This decision should be made in the analysis phase with a written rationale. Switching platform later means rewriting the project from scratch.
Offline capability is an architectural decision, not a feature
Connectivity drops in warehouse aisles, on production floors and in basements. If the app stops working at that point, field teams revert to paper and the project's purpose is lost.
Offline capability requires storing data on the device, queuing operations for transmission when connectivity returns, and defining how conflicts are resolved when the same record is modified in two places. If these three concerns are not designed in from the start, adding them later means rewriting the app's data layer.
The invisible work: back-end
Users only see screens; yet the service layer the app talks to typically accounts for close to half of the total project work. Authentication, authorisation, data validation, ERP mapping and error handling all live in that layer.
If existing systems have no open API, a bridge must be built. When comparing proposals, always ask whether this item is included; proposals that price 'the app' and exclude the back-end are misleading.
Publishing, distribution and handover
If the app will be published in the stores, accounts must be opened in the organisation's name. An app published under the supplier's account becomes a difficult asset to transfer when the relationship ends.
For internal-only apps, an enterprise distribution channel can replace the stores entirely, eliminating review delays and putting version distribution under mobile device management control.
Maintenance: recurring, not one-off
iOS and Android each release a major version annually; library dependencies and store rules also change. An enterprise app with no active maintenance typically starts exhibiting problems on new devices within two years.
The maintenance agreement scope — OS compatibility checks, security updates, bug fixes and planned enhancements — must be defined line by line. 'One year of warranty' does not specify which of these it covers.
Questions on this topic.
For typical enterprise field apps, eight to sixteen weeks. The main factors that extend the timeline are offline capability, the number of systems to integrate, and store review periods. Any timeline given before the scope is written down is an estimate.
With a shared codebase, both platforms are covered by a single development cost; only testing and publishing are run separately. With native development, two separate teams and two separate maintenance tracks are created, and cost increases accordingly.
No. Apps intended only for company employees can be distributed via enterprise methods that bypass the stores, eliminating review delays and keeping version control within the organisation.
Yes. Systems with an open API are connected directly; systems without one are bridged via database or file-based methods. Integration points are identified during analysis and written into the scope document.
Unless stated otherwise in the contract, source code, data model and publishing certificates are handed over to the organisation on completion. This preserves the ability to continue with a different team in future.
