Choosing between web, mobile or both

The right channel depends on where and how users work. A new application can be delivered as a website that runs in a browser, as a native app installed from an app store, or as both. Each choice has real consequences for cost, speed of delivery, maintenance and, above all, how well the software fits the people using it.

The decision is often made on instinct. Someone feels that a serious product needs an app, or that apps are an unnecessary expense. This guide offers a more grounded way to decide, based on the working conditions of your users and the lifetime cost of each option.

Start by watching how people work

Before comparing technologies, spend time with the people who will use the software. Where are they when they need it? At a desk, on a shop floor, in a vehicle, in a customer’s home? Do they have reliable connectivity? Are their hands free? How often will they use it: several times an hour, once a day, once a month?

The answers usually point clearly in one direction. Office staff processing orders all day at a large screen are well served by the web. Engineers inspecting equipment in basements with no signal need something that works offline. Customers who order once a quarter will rarely install an app, however good it is.

• Location: desk, site, vehicle, customer premises or on the move.
• Connectivity: always online, patchy, or often offline.
• Frequency: many times a day, daily, occasionally.
• Device: company laptop, shared tablet, personal phone.
• Device features needed: camera, barcode scanning, location, notifications.

When the web is the right choice

A web application reaches all devices with one codebase and suits office work. Anyone with a browser can use it, on any operating system, with nothing to install. Updates go live for everyone at once, without waiting for app store approval or for users to download a new version.

Modern web applications can be responsive, working well on phones and tablets as well as desktops. For many business tools, such as customer portals, internal dashboards, booking systems and administration screens, that is enough. The web is also usually the cheaper option to build and maintain, because there is one application rather than several.

The limits are real but narrower than they used to be. Web applications have restricted access to some device features, work poorly or not at all without a connection unless specially built for it, and cannot send notifications on every platform in the same way an installed app can. Users also have to remember to open a browser and find the right address, which matters for frequent tasks.

When native mobile is the right choice

Native mobile is best for offline use, device features and field work. An installed app can store data on the device, let people keep working without signal and synchronise when the connection returns. It can use the camera, barcode scanners, location and sensors fully, and send reliable notifications.

Consider a typical inspection team visiting sites with poor connectivity. They need to see their schedule, complete detailed forms, take photographs and capture signatures, often with gloves on and in poor light. A native app designed for those conditions, with large controls and full offline working, will be used. A website that freezes every time the signal drops will be abandoned for paper.

Cross-platform frameworks allow one codebase to produce apps for both major phone platforms, which reduces cost. They suit most business applications well. For apps that need the very best performance or the newest device features, fully native development may still be worth the extra effort.

The middle ground: progressive web apps

Progressive web apps sit between the two. They are websites that can be added to a phone’s home screen, work offline to a degree and, on many devices, send notifications. For some uses they offer much of the convenience of an app at close to the cost of a website.

The trade-off is uneven support across devices and browsers, and less reliable access to some features. They are a good fit when offline needs are modest and users are mostly on modern phones. They are a weaker fit for intensive field work or when deep device integration is essential.

When you need both

Share the back end and tailor each interface. Many organisations need both: a web application for office staff and customers, and a mobile app for people in the field. The mistake is to build two separate systems. The better pattern is a single back end, holding the data, business rules and integrations, with two front ends designed for their users.

The two interfaces should not be copies of each other. The office version might show complex tables, reports and bulk actions. The mobile version might show only today’s jobs, with large buttons and a simple flow. Both read and write the same data through the same interfaces, so information stays consistent and business rules are defined only once.

This pattern also protects you against change. If a new channel appears later, such as a supplier portal, a voice assistant or an integration with a partner’s system, it can connect to the same back end without duplicating logic. The investment in a clean back end and well-documented interfaces pays back every time a new front end is added, and it makes the eventual replacement of either interface far less disruptive.

1. Design the back end and its interfaces first, around business concepts such as jobs, customers and orders.
2. Build the interface used by the largest or most critical group first.
3. Add the second interface once the back end has proved itself in real use.
4. Keep business rules on the server so that both interfaces behave the same way.

Compare the lifetime cost

The build cost is only the beginning. Over five years, a native app typically carries higher maintenance costs than a web application, because each operating system update, new device and app store policy change may require work. If you need both, expect the combined running cost to be noticeably higher than for either alone.

That cost is worth paying when the app genuinely changes how well people can work. It is wasted when an app duplicates a website that would have served users equally well. Ask for a five-year estimate of each option, including maintenance and support, before deciding.

We assumed customers wanted an app. When we looked at how often they actually ordered, a well-built website was clearly the better investment, and we put the app budget into the engineers’ tool instead.

Commercial director, building services client

To decide for your next application, write down the three main user groups, where each works, how often they will use the software and whether they need offline access or device features. If none of them needs offline working or deep device integration, start with the web. If one group clearly does, plan a shared back end with a native app for that group and a web interface for everyone else.

Source: Intelliversal analysis.

Frequently asked questions

Is a mobile app more professional than a website?

Not in itself. Users judge software by whether it helps them do their job. A fast, well-designed web application often serves occasional users better than an app they have to install and update.

Can we start with the web and add an app later?

Yes, and it is often the sensible route. If the back end and its interfaces are designed well from the start, a mobile app can be added later without rebuilding the core system.

Should we build separate apps for each phone platform?

For most business apps, a cross-platform framework producing apps for both platforms from one codebase is the better value. Fully native builds suit apps with demanding performance or device needs.

Explore Custom Application Development