Tolaron
Two pencil sketches of a phone on white paper, one drawn as a browser window and one as a grid of app icons, with a navy pen between them

Do you need an app, or a better mobile website?

By Zdeněk Dolák, Founder7 min read

When a mobile app is worth building and when a faster mobile website serves people better: how often they return, what the phone adds, what an app costs to run.

Plenty of companies ask for a mobile app when a faster mobile website would serve their customers better. An app earns its place when the same people come back often, when it has to keep working without a signal, when it needs something only a phone can do, or when it is the tool staff work in all day. For something a customer does once or twice a year, a website reaches more people, asks less of them and costs less to keep running.

This article sets out the questions we ask before scoping an app, including when the honest answer is that an app is not the right spend. How we work when it is the right answer is on our mobile app development page.

Start with how often one person comes back

An app asks for a lot before it does anything useful: find it in the store, install it, allow notifications, sign in. Every one of those steps loses people, and the ones who get through do not necessarily stay. AppsFlyer, an app-analytics vendor, reports that 46.1 percent of apps installed in 2024 were uninstalled within 30 days; that figure comes from its own Android measurement network rather than from neutral research, but being installed and being kept are clearly not the same thing.

A website is one tap from a search result, a link in an email or a QR code on a door, and the audience is already there: in Czechia, 83 percent of people aged 16 and over used the internet on a phone in 2025.

So the first question is not what the app would do. It is how often the same person will do it.

  • A few times a year. An annual renewal, an occasional order, a form, a price list, an enquiry. A website almost always wins, because the effort of installing an app is repaid too rarely.
  • Every week, or every working day. A service customers actively manage, or a tool your staff use on every shift. Here the installation is repaid, and the app can do things a website cannot.

Between those two, the decision usually comes down to what the next two sections cover.

What a website on a phone can already do

The gap is narrower than it was a few years ago, and several requirements that used to force an app no longer do. A website on a phone can:

  • Open the camera and upload photos or documents from a form.
  • Use the phone's location for a nearby search or to prefill an address.
  • Take payments through Apple Pay and Google Pay in the browser.
  • Sign people in with a passkey confirmed by Face ID or a fingerprint, with no password to reset.
  • Be added to the Home Screen with its own icon and open without the browser bar around it. On Android the site can offer this itself; on the iPhone the person has to do it from the Share menu, and most never think to.
  • Keep showing pages and data it has already loaded when the connection drops.
  • Send push notifications: on Android through the browser, and on iPhone once the user has added the site to the Home Screen.

If your list of "must haves" is covered here, an app is an expensive way to deliver the same thing.

What still needs an app

Some requirements genuinely do need one, and they are worth recognising early:

  • Notifications that reach everyone. On iPhone, web push only works for people who have added your site to the Home Screen, which few will do. An installed app reaches the whole audience that installed it.
  • Real offline work. A whole shift of records captured with no signal, held on the device and synced later. Safari deletes what a site has stored after seven days of browser use without the person returning to that site, so a browser is not where work that has not yet reached your server should be waiting.
  • Anything that has to run in the background. Uploading a queue, syncing when the signal returns, or following a vehicle's location while nobody is looking at the screen.
  • The phone's hardware. Reading NFC cards and tags, talking to Bluetooth equipment such as a printer or a meter, or scanning barcodes continuously at the speed a warehouse needs. Chrome on Android opens some of this to websites; Safari on the iPhone does not expose NFC or Bluetooth to a website at all, so anything that has to work on both platforms needs an app.
  • Devices your company manages. Work apps can be pushed to company phones and removed again by your device management; a website cannot be installed or controlled that way.
  • Being where customers look. If people search the App Store or Google Play for your kind of service, absence from the stores is a real cost, separate from anything technical.

What an app costs after it launches

This is the part that rarely appears in the first conversation, and it decides more cases than any technical feature.

  • Two store accounts. The Apple Developer Program is USD 99 per year, and a Google Play developer account is a one-off USD 25. Both are enrolled in the company's name, with the company's own identifiers.
  • Every change goes through review. Apple states that on average 90 percent of submissions are reviewed in under 24 hours, so this is rarely a long wait, but a fix still reaches people only once the store has approved it and their phone has updated the app.
  • Old versions stay in use. Some people will run last year's version for months, so the API has to keep serving them.
  • Platform deadlines force work in quiet years. iOS and Android release a new version each autumn, and Google Play sets a yearly target API level deadline: since 31 August 2026 an update can only be submitted if the app targets Android 16, and an app that falls further behind stops being offered to new users on newer phones. Even in a year when you add nothing, the app needs attention.

A website has none of this. You deploy once and everyone has the new version, including the person who opens it for the first time.

Five questions that settle it

  1. How often will one person use this, honestly?
  2. Does it have to work with no signal, or with a bad one?
  3. Does it need the camera, NFC, a Bluetooth device or the location in the background?
  4. Do notifications matter enough that people must act on them?
  5. Who keeps it updated for the next three years, and from which budget?

The first question sets the frame, the middle three test whether an app is technically necessary, and the last one decides whether you can keep it alive. If one person would use it a few times a year and questions two to four are all "no", put the money into a faster, clearer mobile website instead. Two or three "yes" answers in the middle, and an app is worth scoping properly.

Often the answer is both

For many companies the split is not app against website but who each one is for. The public side stays on the website, where search engines, links and first-time visitors can reach it. The app is for the people who come back: regular customers, or staff who need it to work offline and to use the phone's hardware.

When both run on the same API, this costs far less than building two separate products. What that API needs to support is covered in what your API needs before we build a mobile app.

Next step

If you are weighing this up, a short summary is enough to get a straight answer: who the users are, the main task, and how often one person would do it. You can send it through the contact page. If a website is the better answer for your case, we will say so.

Sources