Skip to content
Algori Systems

Do you need an app, or will a website do

The install barrier is the hardest part of shipping an app, and it has nothing to do with building it. When a website is the better answer, and the four cases where it is not.

A phone lying flat under a cluster of glass cubes floating above its screen, lit in magenta and purple.

We build mobile apps. We also talk a fair number of people out of them, usually in the first conversation, and usually because the thing they described is a website that they have pictured as an app.

The honest default for a small business is a website first. Here is the reasoning, and then the cases where it does not apply.

The install barrier is the real cost

Building the app is the part everyone plans for. Getting it onto a phone is the part that decides whether it was worth building.

A website needs one thing from a visitor: tapping a link. An app needs them to go to a store, search for you, choose to download, wait, open it, and often create an account before seeing anything. Every one of those steps loses people, and they compound. Then the app has to survive the periodic clear-out when storage runs low, which is a competition it will lose to anything used less than weekly.

So the question is not whether an app would be nice. It is whether a customer would install one for you, and then keep it. For a business most customers deal with a few times a year, the honest answer is usually no, and an app nobody installs is worse than a website everybody can reach, no matter how good it is.

The costs that arrive after launch

An app is not a thing you build once.

Two platforms means two builds, two sets of behaviour and two things to test, unless you use a cross platform framework, which is why we use Flutter for nearly all of it. One codebase produces both, which roughly halves the build and, more importantly, halves every change you make afterwards.

Both stores review what you submit, on their schedule rather than yours. A bug fix on a website is live in minutes. The same fix in an app waits for review, and then waits again for users to actually update. Apple and Google also change their requirements periodically, and when they do you update or you get removed, whether or not you had any other reason to touch the app that year.

None of that is a reason to avoid apps. It is a reason to be sure before starting, because the maintenance floor is meaningfully higher than a website's and it never goes back down.

What the web can already do

A lot of what people want an app for, a modern website does.

It works on every phone with no install. It can be added to the home screen, where it gets its own icon and opens without browser chrome, which covers a surprising amount of what "feels like an app" means to people. It can use the camera, find a location, work offline to a degree, and take payments. It is searchable, linkable, and shareable, none of which an app is.

That last point gets underrated. You cannot send someone a link to a screen inside an app the way you can to a page. For anything you want customers to find, forward or post, the web is not the compromise, it is the better medium.

When an app is genuinely the answer

Four situations, and they are reasonably easy to recognise.

Daily or near daily use by the same people. Frequency is what earns the icon on the home screen. A fitness tracker, a delivery driver's job list, a tool your staff open every shift. If somebody will use it most days, installing it is a fair trade.

Real device integration. Sustained background location, hardware sensors, tight camera work, connecting to physical equipment. The web has been closing this gap for years but it has not closed it.

Genuine offline operation. Not "the connection is sometimes slow", but people working in places with no signal, all day, who need the thing to function and sync later.

Notifications that matter enough to be allowed. This is the most common reason clients give and it deserves a caveat. Push notifications only work if people permit them, and they are permitted for things people already care about. A notification is the reward for being useful, not a way to become useful.

The fifth case, which does not fit the pattern but is real: an internal tool for your own staff. You control the devices, installation is not a barrier, and nobody is going to delete it. Many of the strongest arguments for an app are about employees rather than customers.

The way to decide

Ask how often one person would use it. Weekly or more, and an app can earn its place. Monthly or less, and you are asking someone to keep something on their phone that they will forget they have.

Then ask what it does that a browser cannot. If you can answer that in a sentence involving hardware, offline work or genuine daily use, build the app. If the answer is that it would feel more professional, build the website, and build it well enough that the question stops coming up.