Mobile app or web app for service businesses

A customer wants to book an appointment, check a service date or download a document. Will they install an app to do that? Not necessarily. A service technician who completes jobs in the field every day, on the other hand, may need access to data even without internet. For them, a mobile app may be the most convenient work tool.

The choice between a mobile app and a web app should therefore not start with technology. First you need to establish who will use the solution, how often and in what conditions. Only then can you decide whether the user needs a site accessible via a link, an app installed on the phone, or a combination of the two.

How does a web app differ from a mobile app?

A web app is an application that runs in the browser. The user opens it via a web address and can use it on a phone, tablet or computer. A well-designed web app adapts its interface to the screen size, lets users log in to their account and carry out actions such as booking, paying for a service or tracking a request.

A mobile app is installed on the device, usually through the App Store or Google Play. It can be built separately for iOS and Android, or with a technology that lets you develop both versions on a shared codebase. How it is built affects cost, development speed and the scope of integration with the phone.

There is also the PWA, a web application with additional capabilities. Depending on the browser and device, the user can add it to the home screen, run it in an app-like view and use selected features offline. The range of available capabilities must, however, be checked separately for the devices on which users will work. MDN describes how PWAs are made installable and how service workers, used among other things to handle offline resources, work.

When is a web app the better choice for a service business?

A web app works especially well when the customer uses the service occasionally. They can click a link in a message, an ad or search results and go straight to taking action. They do not have to install a program and create an account first just to check the available dates.

Imagine a company that runs training courses. A potential customer wants to see the programme, choose a date and pay. If the whole process works smoothly in the phone’s browser, having to install an app would be an extra step between interest and purchase.

It is worth considering a web app when:

• the main goal is to win new customers through search engines, ads or shared links;
• users visit the system a few times a year, for example to book a service;
• the solution is used on both phones and computers;
• the company wants to update its offer, forms and process flow quickly;
• you need a customer portal, a booking system, a configurator or a portal for handling requests.

Access via a link is also convenient for communication. The company can send a customer a direct link to a payment, a document or the status of a case, instead of explaining where to find a given feature once the app is open.

When is it worth building a mobile app?

A mobile app makes more sense when the user returns to it often and the phone is their main tool. Installation then becomes a small effort compared with the convenience of everyday use.

A good example is an app for field technicians. The worker can receive new jobs, check addresses, take photos of completed work, collect signatures and complete a report. If part of the work takes place in areas with poor signal, designing on-device data storage and its later synchronisation becomes especially important. This is a separate element of the architecture that has to be planned and tested; installing the app does not by itself make it work offline. The Android documentation describes principles for designing apps in which local data remains available without a connection.

A mobile app is also worth considering when frequent customer returns, quick access from the phone’s home screen, notifications or intensive use of the camera, location and other device features are an important part of the service.

We need to be careful not to oversimplify here: notifications are not exclusive to mobile apps. Under certain conditions, web apps can handle them too. For example, Apple documents sending web push notifications to supported web apps. The choice of technology should be decided by the specific scenario and how it works on customers’ devices, not by the word “notifications” alone. See Apple’s documentation on web push.

A comparison from the perspective of a service business

This comparison shows typical differences. The final capabilities depend on the technical design: a poorly built mobile app can perform worse than a good web app, and an extensive web application can handle far more than a simple form on a website.

The key question: how often will the customer come back?

Frequency of use is one of the best starting points for the decision.

If a customer needs the service once or twice a year, installing an app may be an unnecessary barrier. This applies, for example, to a one-off consultation, a repair, a hotel booking or a quote request. In such cases, easy entry via a link and a short path to completing the task are especially important.

If, however, the customer uses the service several times a week, the situation is different. In an app for people who train regularly, use medical services or manage many jobs, quick access to the calendar, history and current actions may justify installation.

It is also worth separating two groups of users. A company’s customers may need a web app, while its employees need a mobile app. One product does not have to impose the same form of access on everyone.

Is a PWA a compromise that solves everything?

A PWA can be a good step between a classic web app and an app installed from a store. It keeps easy access via a link while providing selected app-like features, such as an icon on the home screen.

However, you should not assume that a PWA will always replace a mobile app. If the success of the service depends on a specific device feature, background operation or reliable offline work, you need to prepare a list of required actions and test them on the target phones and browsers. Such a test tells you more than a general comparison of technologies.

For many companies, a sensible first stage looks like this: launch a convenient web app, observe user behaviour, and then decide whether to develop it as a PWA or build a mobile app. This is not a mandatory order. If it is known from the start that employees work in the field every day without a stable internet connection, mobile requirements must be taken into account from the outset.

How do you compare the costs of the two options?

Comparing only the cost of building the first version is not enough. You also need to take into account development, testing, integrations, maintenance and user support.

For a web app, the relevant factors include interface design for different screens, infrastructure, security, performance and browser compatibility. A mobile app adds testing on devices and operating systems, publishing in the stores and maintaining the versions used by customers. Apple points out that apps submitted to the App Store go through a review process, which must also be factored into the release plan. See the description of the App Review process.

The scope of the product often has more impact on the budget than the “web or mobile” choice itself. Login, payments, bookings, calendar synchronisation, CRM integration, several user roles and offline mode are separate areas of work. That is why, before pricing, it is worth listing the specific actions performed by the customer and by the employee.

Instead of asking only “how much does a mobile app cost?”, it is better to ask: how much will it cost to launch and maintain the entire service-handling process in the chosen model?

Examples of decisions for different services

A service salon or clinic. The customer wants to find a slot, book an appointment, pay and receive a reminder. If they use the services from time to time, a web app accessible via a link is a good starting point. A mobile app may make sense later, once frequent use, a loyalty programme or broader customer service develops.

A field service company. The customer reports a fault through a form and checks the status in the browser. The technician uses the phone every day during visits, takes photos and completes the protocol. Here it is worth considering a web app for the customer and a mobile app for the field team.

A training platform. The participant buys a course from an ad or a search engine and then uses the materials on different devices. A web app lets them start conveniently without installing anything. If a strong habit of daily learning and phone-based features emerge later, the case for a mobile app can be assessed separately.

How do you make the decision before starting the project?

Before choosing a technology, answer five questions:

• Who uses the solution: the customer, the employee or both groups?
• How often will each group come back to it?
• Does the user need to work without internet or make intensive use of phone features?
• Where will they reach the service from: a search engine and ads, a shared link, or regularly launching the app?
• Which three actions must they be able to perform in the first version for the product to bring value to the company?

It is worth turning the answers into a simple user journey map. If its most important moment is a quick booking via a link, designing two mobile apps from the start may lengthen the road to launching sales. If the most important moment is completing a job in the field with no signal, ignoring offline work will create a problem regardless of how good the interface looks.

Summary

A web app usually makes it easier to start using a service and works well when the customer reaches the company through a link, a search engine or an ad. A mobile app gains importance with frequent use, daily work on the phone and requirements that have to be closely tied to the device. A PWA can be a useful option, provided its specific capabilities match users’ needs.

The best choice follows from the service process, not from fashion for a given type of app. At Internet Stars, we help companies describe that process, choose the scope of the first version and build a solution that fits their customers and the way their team works. If you are wondering which option is right for your service, let us start with a short analysis of what users actually need to do in the app.