When should a business build a mobile app?

An app introduces a commitment for both the business and the user. The business must maintain it, while the user must discover, install, and return to it. The proposed experience should justify that effort. A clear mobile-specific purpose is a better starting point than the desire to appear more established.

Identify the recurring job the app will do

Describe the situation in which someone reaches for their phone. A technician may need to record a site visit, a customer may need to track a regular delivery, or a member may need to manage recurring appointments. The context tells you what information must be available and how quickly the task should be completed.

Consider frequency as well as importance. An annual enquiry rarely justifies asking someone to install software. A daily operational task may. Interview intended users about their current behaviour and observe where a mobile experience would remove friction. Do not assume that interest in your brand translates into willingness to keep an app.

Compare a responsive website, PWA, and app

A responsive website is accessed through a browser and can provide a good experience across screen sizes. A progressive web app can add capabilities such as installation and more resilient behaviour, depending on the browser and device. A platform-specific or cross-platform app may offer a different set of integration and distribution options.

The boundaries vary by capability and platform, so evaluate the actual requirements. Check the devices, operating environments, and permissions involved. Avoid choosing based on a generic feature chart alone. A short technical proof can establish whether the intended scanning, offline, or notification workflow behaves as expected for your users.

Device features should support the journey

Camera access, location, notifications, and offline storage can be valuable when they reduce work. For example, photographing a completed installation may be more useful than typing a long description. But requesting permissions without a clear reason can make the experience harder to trust and more difficult to use.

Ask what happens when permission is declined or the feature is unavailable. A location-dependent process may need a manual alternative. A notification should not be the only place important information exists. Design around realistic conditions rather than assuming every user has a current device, reliable connectivity, and all permissions enabled.

Example: a field service workflow

Suppose technicians receive jobs by message and later enter notes into an office system. A mobile app could show assigned visits, capture completion information, and prepare a report. The business case depends on whether that workflow reduces duplicate entry and improves the completeness of the record.

Offline behaviour may be central to this use case. Decide which information remains available without a connection, how unsent changes are shown, and how conflicts are resolved when the device reconnects. Test interrupted uploads and repeated submissions. A polished screen is not enough if staff cannot tell whether their work has been saved.

Plan adoption and distribution early

For a public app, consider how customers will discover it and why they will return. For an internal app, decide how staff receive access and how devices are managed. Account creation, onboarding, and recovery should be proportionate to the task. Avoid making people complete a long setup before experiencing any value.

Distribution arrangements and platform policies can affect release planning. Confirm current requirements with the relevant platform before committing to a launch date. Also plan how users will receive updates and what happens when an older version remains in use. The operational model matters as much as the first installation.

Include maintenance in the decision

An app needs more than a one-time development budget. Device and operating-system changes, backend updates, support, and monitoring require ongoing attention. If the app connects to a web platform, changes to shared data or permissions must be coordinated so the experiences remain consistent.

Ask who owns the application accounts, signing arrangements, source code, and release process. Document how issues are reported and prioritised. A business should not depend on a single person's device or personal account to publish updates. These ownership details are easier to resolve before the first version is delivered.

Validate before building every feature

Start with a prototype of the mobile-specific journey and test it with representative users. Measure whether they can complete the task and whether it improves on the current approach. Then build a limited release with the few capabilities necessary to test repeated use.

Use adoption evidence to guide expansion. Installation counts alone do not show that the app is useful. Look at completed tasks, repeat behaviour, support requests, and the reasons users return to the old process. If the core workflow is not valuable, adding a news feed or loyalty feature is unlikely to repair it.

Mobile app decision checklist

• The app solves a recurring task in a recognisable mobile context.
• Device features provide a clear advantage over the existing experience.
• Connectivity, permissions, and older devices have been considered.
• Distribution, account ownership, and updates have named owners.
• The budget includes operation and maintenance after launch.
• A limited pilot can test meaningful usage rather than downloads alone.

Frequently asked questions

Is a mobile-friendly website enough for most enquiries?

It may be, especially when users visit occasionally to read information, compare services, or contact the business. Test the journey first. An app is more compelling when it offers recurring utility that is difficult to deliver as conveniently through the existing website.

Should we build for both major mobile platforms immediately?

Base the decision on your audience and distribution needs. An internal pilot may use a known device fleet, while a public service may need broader coverage. Confirm the scope and maintenance implications before choosing a platform strategy or promising simultaneous releases.

Can we reuse our existing business systems?

Often yes, if those systems provide suitable interfaces and permissions. Review the integration before committing. The mobile application should not create an uncontrolled second version of important information; define data ownership and synchronisation behaviour as part of the design.