Development

Mobile app or mobile website

An app is justified not by the size of the business but by the usage scenario. What installation gives you, what two platforms and app stores cost, and when a website is enough.

The question "do we need an app" is almost always asked in terms of presence: competitors have one and we don't. It should be answered in terms of the scenario: what a person will do, how often and under what conditions. An app isn't a more serious version of a website but a different delivery method, with specific advantages and an ongoing cost.

The main barrier is installation

Between an ad and an app's first screen stands installation: find it in the store, wait for the download, grant permissions, sometimes sign up. Every step loses some people, and it's the most expensive point in the whole undertaking.

Hence a simple rule: an app works for people who are already your clients and barely works for attracting new ones. Someone who has just heard of the company won't install software for a single action. They'll open a page.

So the most common combination is: the website attracts and explains, the app serves repeat use. If your scenario has no repeat use, there's nothing to pay back the installation barrier.

What installation really gives you

There are capabilities that are either unavailable in a browser or work noticeably worse there. It's these, not image, that justify the project.

Push notifications. A direct channel to the person's lock screen. For delivery, taxis, appointments and status alerts, it's a key feature. Browser notifications exist, but their support and behaviour vary across platforms, and people are reluctant to grant permission.

Working offline. If the user works in the field, in a warehouse, in a basement or while travelling, an app can store data locally and sync it later. A website in that situation simply won't open.

Camera, sensors, geolocation. Scanning barcodes and documents, photo evidence, background route tracking, working with Bluetooth devices. Some of this is available in a browser, but with limitations, and as soon as background work is needed — only an app will do.

Speed and smoothness under intensive use. If a person spends hours in the interface, the difference in responsiveness adds up.

An icon on the home screen. Prosaic but significant: an app is seen every day; a website has to be remembered.

If your scenario has none of the items on this list, the chances that an app will pay off are low.

When a responsive website is enough

The opposite signs are just as recognisable:

  • The user visits rarely and irregularly: once a month, once a quarter, once a year.
  • The main scenario is viewing information, comparing, leaving a request.
  • Arriving from search and links matters: an app can't be found in search.
  • A link to a specific screen needs to be shareable with a colleague or client.
  • The audience is diverse, including people for whom installing something is itself difficult.
  • Content and features change often, and you don't want to wait for each user to update.

The last point is underestimated. A website has one version, and it's always current. With an app, part of the audience stays on an old version for months, and you have to support both.

It's also worth mentioning the in-between option: a website that can be added to the home screen and partially works offline. It covers the icon and basic notifications, doesn't require two platforms and an app store, but in capabilities it stays closer to a website than to an app. As a task it's closer to a web application than to mobile development.

What two platforms cost

There won't be specific figures here, but the cost structure matters more than the figures.

  1. Two platforms aren't one project. iOS and Android differ in interface guidelines, notification mechanics and background behaviour. Even with a shared codebase, part of the work is done twice, and testing is needed on both.
  2. Devices and versions. Android means many screens and OS versions. Testing takes noticeably longer than for a website, where there are essentially only a few browsers.
  3. You still need a backend. An app is a client. Data, accounts and logic live on the server, and that's a separate part of the project, independent of the number of platforms.
  4. Publishing in app stores. Developer accounts with annual or one-off fees, preparing descriptions and screenshots, a privacy policy, answering review questions. Review takes time, and rejection for a formal reason is common.
  5. Updates go through the same procedure. An urgent fix on a website goes live immediately. In an app it goes through review and then waits for users to update.
  6. Platform requirements change. New OS versions, new rules on permissions and data. An app left untouched for a year may stop being accepted in the store or break on a fresh OS.

Developing an app is a one-off expense; having an app is an ongoing one. If there's no budget for the second, don't start the first.

Support as an ongoing expense

This is the part people regularly forget to budget for, and it's why apps quietly die.

  • Annual developer account fees.
  • Regular updates for new versions of iOS and Android.
  • Library updates, including those that patch vulnerabilities.
  • Handling app store reviews and crash reports.
  • Backend upkeep: server, backups, monitoring.
  • Supporting old app versions for people who haven't updated.

An abandoned app is worse than none: a low rating, complaints about crashes and a sense that the company gave up on something halfway. If you're not ready to support it for years, it's more honest to build a good mobile website.

How to decide in your situation

Answer the questions honestly, about the current state of affairs, not your plans.

  1. How often will a person open the product? Daily or weekly — an app is worth discussing. Monthly or less — no.
  2. Does the scenario include at least one thing from the capability list: push, offline, camera, sensors, background work? If not, "an app" isn't an answer for this task.
  3. Where will users come from? If from search and ads, they need a page first. An app can come later, for an existing base.
  4. Do you have a client base you can offer the installation to? Without one, nobody will install the app.
  5. Is there money budgeted for support several years ahead? If not, the project will end in a year.
  6. Is link sharing needed? If users send each other specific screens, the web is more convenient.

A practical sequence for most: first a mobile website or web application, then — based on accumulated user behaviour — a decision about a native version. By that point you can see who visits regularly, which capabilities are missing and whether installation will pay off. The conversation about an app then becomes concrete rather than a comparison with competitors. An overview of all areas is in the services section.