A business mobile app is a program on a phone or tablet through which employees, customers or partners do business with your company even when they are away from a computer. It differs from a web application in its access to the device's capabilities: the camera, location, notifications and data stored on the device itself.
When a mobile app makes sense
Field work
For service technicians, sales representatives, delivery, installation and site visits: work orders, checklists, photos, the customer's signature on the screen and location, even where the signal is weak.
Customer apps
Orders, bookings, a loyalty programme, service status or fault reporting. A customer app makes sense when your customers come back often enough for it to be worth installing.
Internal apps
For employees away from the office: records, approvals, stocktaking by scanning barcodes, internal announcements and an overview of ERP data.
When a web application is enough
If users mostly work at a computer or open the application only now and then, a web application is simpler to build and maintain: it runs in the browser, does not go through app store review and updates immediately for everyone. As a progressive web app, it can also be added to a phone's home screen. There is more on this on our web application development page. A mobile app has the edge when you need offline working, the camera and scanning, location or reliable push notifications.
Native or a shared codebase
When developing mobile apps for Android and iOS, you choose between native development and a shared codebase. Neither approach is always better, so we choose after discovery and explain our choice.
Native development
Native development means a separate app for each platform, built with the tools Google and Apple recommend: Kotlin and Jetpack Compose for Android, Swift and SwiftUI for iOS. The advantages are full access to the device's capabilities, the behaviour users are used to on their platform, and access to new system features as soon as they are released. The drawback is separate code for each platform, so development and maintenance take more work. For Android, we work in Kotlin and Jetpack Compose, which our own mobile product is also built on.
A shared codebase
Here most of the code is written once, and the apps for both platforms are built from it. The advantages are less work on development and maintenance, and the same features on Android and iOS. The drawbacks are an extra layer between the app and the operating system, occasional delays in support for new device features, and parts that still have to be written separately for each platform.
When choosing, we look at which devices users have, how much the app relies on the camera, Bluetooth, location and background work, how important a platform-native look is, and who will maintain the app. If all users have company Android devices, an Android app alone is often enough.
Working without an internet connection
In the field, a signal is not guaranteed, so the app stores data on the device and sends it when the connection returns. It is agreed in advance what may be done offline, what happens when several people change the same record, and which data may remain on the device if it is lost. Working this way takes more development and testing, but for field work it is often decisive.
Push notifications
A push notification appears on the screen even when the app is not open: a new work order, an approved request, a change in an order's status. Notifications are sent through the services Google and Apple provide for this, and the user has to allow them. They are useful when they are rare and important, because too many notifications usually end with users switching them off.
Connecting to your systems
A mobile app takes data from your ERP, CRM or other systems and sends back what was done in the field. Between the app and those systems, we build a backend on Node.js and PostgreSQL that checks permissions, stores data and talks to the ERP or CRM through an API. That way the phone has no direct access to your ERP, and the same backend can also serve a web application. The backend runs on servers in the EU. A mobile app is often part of a larger system, and how we build such systems is described on our custom software development page.
Publishing on Google Play and the App Store
A customer app is published on Google Play and the App Store. We recommend publishing it under your company's developer accounts, so that it stays yours in the stores as well. Publication requires an app description, screenshots, a privacy policy and a declaration of what data the app collects. Both stores review the app before publication and when it is updated, and may ask for changes. Internal apps do not have to be public: they can be shared only with employees, through private distribution in the stores or through a system for managing company devices.
How we build a mobile app
- A free first call: who uses the app, on which devices and in what conditions.
- Discovery and choice of approach: native, a shared codebase or a web application, with our reasoning.
- Scope, cost estimate and a phased plan.
- A first working version in 4–8 weeks, installed on the devices of the users who test it. You follow progress in the client portal.
- Testing in real conditions, improvements and publication in the stores.
- Maintenance after publication.
Maintenance
A mobile app needs more maintenance than a web application. Google and Apple regularly release new versions of their operating systems and change the store rules, and an app that does not keep up can lose the ability to be updated or become unavailable to new users. Maintenance covers adapting to new versions of Android and iOS, security updates, error monitoring, new releases in the stores and maintaining the backend.
What the price depends on
The cost estimate depends on:
- one platform or both, and the chosen development approach;
- offline working and data synchronisation;
- the camera, scanning, location, Bluetooth and background work;
- the number of screens, roles and business rules;
- integrations with your ERP, CRM and other systems;
- design and accessibility requirements;
- the scope of maintenance and how often new releases come out.
What to prepare
Before the first call, it is worth preparing:
- a description of the users and the conditions they work in: office, field, warehouse, places with no signal;
- information about the devices: company or personal, Android, iOS or both;
- examples of the forms, work orders and reports the app replaces;
- the API documentation for the systems the app connects to;
- for public release, developer accounts with Google and Apple in the company's name, for which both stores require a D-U-N-S number, and a privacy policy;
- a person who decides on priorities, and a few future users who will try out the working versions.