Can a web app be turned into a store app later?

Often yes, and it is a common route: the web version carries the work, and a thin native shell puts it in the stores once there is evidence people want it installed. What does not carry over automatically is anything that needs real device access, so if background notifications or offline use are the point, say so at the start rather than after the fact.

Will customers take us less seriously without an app?

For most service businesses, no. What people judge you on is whether the thing they came to do works quickly on a phone. An app that is rarely opened tends to read as neglected, in the same way an abandoned social profile does, so an unused icon is not the credibility signal it looks like from the outside.

What makes a mobile app cost more than a web app?

Mostly that there is more than one of it. Two platforms means two builds, two sets of device behaviour, two store listings and two releases every time something changes, even where a shared codebase covers most of the work. Add store review, older versions still installed on people's phones, and the ongoing job of getting anyone to install it at all.

Do we need both iOS and Android?

That depends on who your customers are, and it is worth checking rather than assuming. Launching on one platform first is a legitimate way to test whether the install is wanted, at the cost of everyone on the other platform being unable to use it. A web app avoids the question entirely, which is part of the argument for starting there.

Decision guide

Mobile app or web app: which should a small business build?

Most businesses asking for a mobile app are describing something a link could already do, and the question that separates the two is how often one person will come back.

Published on 15 August 20266 min read

The question usually arrives from outside. A customer asks whether you have an app, a supplier mentions theirs, and the site you already have starts to feel like the smaller option. By the time anyone gets around to asking a developer, the decision has quietly already been framed as an app versus everything else.

Two separate things get merged in that moment. One is what the thing does. The other is how people get to it. A mobile app and a web app can do most of the same work now, and where they genuinely differ is in how somebody reaches them. That difference decides almost everything else.

Mobile app or web app: what actually separates them?

A web app runs in the browser, so somebody opens a link and is already in it. A mobile app is installed from a store, sits on the home screen, and can reach parts of the phone a browser cannot. The building work overlaps heavily. The distribution does not, and that is the real decision.

The install is the part people underestimate

A link is one tap. An installation is a store listing, a download, a permissions prompt, storage on a phone that is probably full, and a reason to bother. Every one of those steps loses people, and they lose them before anyone has seen what you built.

That cost is worth paying when the relationship is ongoing. If somebody deals with you weekly, the icon on their home screen is a standing invitation and the install pays for itself in return visits. If they deal with you twice a year, you are asking a stranger to keep you on their phone in exchange for something they will use once and forget.

There is also a discovery problem nobody mentions in the pitch. Almost nobody searches an app store for a business they have not already heard of. Installs come from people you reached somewhere else, which usually means the website you were about to treat as the lesser option.

Being used on a phone and being installed on a phone are different requirements. Only one of them commits you to a second release track. A web app on a phone is still a phone-first product, and that is what most people actually mean when they say their customers are all on mobile.

What a store app can do that a browser cannot

Reach somebody when nothing is open. Notifications from a browser do exist, but they behave differently from one phone to the next and some of them depend on the site having been added to the home screen first. If a reliable nudge is the entire point of the product, that unevenness is the strongest argument for installing.

Work properly with no connection. Not a cached page, but full use in a basement, a van, a lift shaft or a field, with everything syncing later. Browsers can store a surprising amount offline, and they are still the wrong tool when offline is the normal condition rather than the exception.

Reach the device itself. Background location, bluetooth hardware, continuous sensors, tight control of the camera, anything running while the app is not in the foreground.

Carry sustained, heavy use. Something a person has open for an hour at a time, all day, as the tool they do their job in.

If your idea does not need at least one of those, the store is not selling you capability. It is selling you an icon.

What the browser already does

More than most people assume, and this is where app pitches quietly overclaim.

Taking a photo or uploading one from the gallery. Location for a single request, such as finding the nearest branch. Payments, including the cards and wallets already saved on the phone. Logins that survive between visits. An icon on the home screen, added without any store being involved, opening full screen with no browser furniture around it.

That last one is worth sitting with. A web app added to the home screen looks like an app to the person using it, opens like one, and is updated the moment you publish rather than whenever they next update their phone. The distinction people think they are paying for is frequently already there.

Four questions that settle it

Answer these about the specific thing you are picturing.

How often will one person use it? Weekly or more, an install can earn its place. A handful of times a year, the browser wins outright and it is not close.

Does it have to work with no signal? If the answer is a genuine yes rather than a nice-to-have, that is the clearest case there is for a native app.

Does it need to reach people when it is closed? Reminders, alerts, a job coming in. If the whole value is in the interruption, the install is doing real work.

Do people who have never heard of you need to use it? Then it has to be a link. Anything you cannot send by message, email or search result starts every relationship with a barrier.

If the answers are: occasionally, no, no, and yes, you are describing a web app, and you would be building the mobile version to satisfy a feeling rather than a requirement.

What a store app asks of you afterwards

There are two of everything. Two platforms, two sets of device behaviour, two store listings, and two releases every time a price or a phone number changes. A shared codebase covers a lot of that. It does not remove it.

Releases stop being immediate. A change goes through review before anyone gets it, and old versions stay installed on phones that never update. Support for a version you shipped months ago is part of the deal. On the web, everyone is on the current version the moment you publish.

The listing is a job. Store policies change, account requirements change, screenshots need redoing at new device sizes, and none of that is triggered by anything you did.

Getting it installed never stops being your problem. A website earns visitors from search for years. An app earns installs only for as long as you keep asking for them.

What we usually suggest

Build the web version first, even when a store app is the honest eventual goal.

It is one thing to build, anybody can reach it from a link, and it starts collecting the evidence you need for the second decision. How many people came back. How often. Which part they use, and whether they asked for anything the browser could not give them. Those numbers make the case for a native app far better than a hunch does, and if they never appear, you have saved yourself the second release track.

The customer who asked whether you have an app was almost always asking for something narrower than an app. They wanted to book, or check a status, or reorder the same thing as last time. Working out which of those they meant is a more useful conversation than the category question, and it quite often ends with a link rather than a listing. If that is where yours ends, we will tell you so.