The request arrives fully formed: we need an app. Sometimes it's a board asking, sometimes a competitor shipped one, sometimes it's the genuine sense that a website isn't enough any more. Then you ask what the app should do, and the answer describes a set of pages — a catalogue, a booking flow, an account area — that a website does perfectly well.

This isn't a trick question and there's no universally right answer. But there is a way to decide that takes an afternoon instead of a quarter, and it starts by being precise about what an app actually buys you.

The short answer

Build a native app when your product needs something only the operating system can give it — reliable notifications, offline use, camera or sensor access, background activity, biometric login — or when people will use it repeatedly and want an icon on their home screen. Build a website when you need to be found, shared, and opened by people who have never heard of you. Most businesses need the second thing first.

That's the whole decision in two sentences. The rest of this post is the detail behind it, because the trade-offs get concrete quickly.

What can an app do that a website can't?

A real list, not a marketing one. These are the capabilities where the gap is genuine in 2026:

• Notifications you can rely on. Websites can send push on Android and, since iOS 16.4, on iPhone too — but only for sites the user has deliberately added to their home screen. Native apps get it on both platforms as a matter of course.
• Working offline, properly. Not 'the last page you visited is cached' but hours of use with no signal and a sync when the connection returns. This is the single most common reason we've built native.
• Hardware and sensors. Continuous GPS in the background, Bluetooth peripherals, NFC, barcode scanning at speed, the camera used as a tool rather than a file picker.
• Biometric login and secure local storage, backed by the device's hardware keystore.
• Being on the home screen. Not a technical capability, a behavioural one — an icon in someone's pocket gets opened; a bookmark does not.
• Store distribution. For some categories the App Store and Play are genuine discovery channels, and being absent from them reads as being unserious.

What does a website do better?

Everything to do with reach, and most things to do with cost:

• It can be found. Search engines index websites, not apps. Assistants cite web pages, not app screens — which is the whole subject of showing up in AI search. Nobody discovers you by browsing an app store for a category they didn't know existed.
• There's no install. Every step between intent and use costs you people, and 'download a 60 MB app, create an account, verify an email' is several steps. A link opens.
• It's shareable. A URL goes in a message, an email, a WhatsApp group, a search result, an ad. There is no app equivalent of sending someone the exact screen you're looking at.
• One codebase, one deploy. You ship a fix in the afternoon rather than submitting a build and waiting for review — and every user is on the new version instantly.
• It's cheaper by a wide margin, both to build and to keep alive.

What about a PWA — the in-between option?

A progressive web app is a website built so it can be installed to the home screen, run without browser chrome, work offline to a degree, and send push notifications. It's one codebase serving both a public website and something that behaves app-like for regulars. When it fits, it's excellent value.

It fits comfortably on Android. On iPhone you should go in with clear eyes, because Apple's implementation has real edges — and it's usually the iPhone half of the audience that decides whether a PWA is enough:

• Push works only after the user adds the site to their home screen via the share sheet. There's no automatic install prompt the way Android has, so you have to teach people a gesture most have never used.
• Storage for infrequently used home-screen web apps can be evicted after roughly a week of disuse, taking cached data with it. Fine for a shop; not fine for a field tool that must work on day nine.
• Background work is limited. If you need something to happen while the app is closed, this isn't your architecture.
• You're not in the App Store, so you lose that discovery surface and the credibility some audiences attach to it.

The direction of travel is positive — iOS 26 now opens home-screen sites as standalone web apps by default — but the capability ceiling is still Apple's to set. Decide against today's behaviour, not next year's roadmap.

Five questions that usually settle it

1. 01How often will one person use this? Daily or weekly points to an app. Monthly or occasionally points to a website — nobody keeps an icon for a thing they use twice a year.
2. 02Do you need to reach people who don't know you exist? If discovery matters at all, you need the web regardless. That may mean web first, app later — rarely app only.
3. 03Does it have to work without a connection? Genuinely, in the field, for hours? That's the strongest single argument for native there is.
4. 04Do you need to interrupt people? If your value depends on a notification arriving reliably on both platforms — a delivery update, a shift alert, a time-critical reminder — native is the safe answer.
5. 05Can you afford two of everything, forever? Two platforms, two release cycles, two sets of crash reports, indefinitely. Not just to launch — to keep alive.

If four of the five answers point one way, you have your decision. If they're split, you almost certainly want a strong website now and a scoped app when usage proves the case.

What an app actually costs after launch

Build cost is the number everyone compares, and it's the least interesting one. The ongoing cost is what surprises people:

• Developer accounts: the Apple Developer Program runs at 99 USD a year; Google Play charges a one-time 25 USD registration. Small, but they never lapse quietly — an expired Apple account pulls your app from the store.
• Two operating systems that update every year, occasionally in ways that break things you didn't touch. Budget maintenance releases even in quarters where you ship no features.
• App review sits between you and your users. Most submissions clear in a day or two; the one that doesn't will be the urgent fix.
• Users who never update. A meaningful share of your audience will run a months-old version, so your server has to keep supporting it — which constrains how fast you can change anything.
• Store presence as an ongoing job: screenshots, descriptions, review replies, ratings prompts, policy changes.

One more that isn't a line item: the accounts have to be yours. An app published under a contractor's developer account is genuinely painful to move later, and moving it can put your reviews and ranking at risk. Get that right on day one — it's the cheapest it will ever be.

When we've said build the app

Prottoy is the clearest example in our portfolio. It's used in remote districts of Bangladesh, largely on mid-range Android, often with patchy connectivity, by people who open it as part of their working day. Offline capability wasn't a nice-to-have; sign-up completion on low-end hardware was the metric the whole build was judged on. Every argument pointed the same way.

The counter-example is just as instructive. For Al-Bayt Elegance, a modest-fashion storefront, an app would have been a mistake. Customers arrive from search and social, buy occasionally, and share links with each other. What that business needed was a fast, bilingual, beautifully photographed website — which is why the engagement went into performance and storefront experience instead of an app nobody would have installed.

A sequence that de-risks the decision

1. 01Write down the one job the app must do that a website can't. If you can't finish that sentence with something specific, stop here — you want a better website.
2. 02Ship the web version of that job first. It's faster, it's cheaper, and it gives you real usage data instead of opinions.
3. 03Watch the numbers that predict app value: repeat visits per user, how many people add it to their home screen, how many ask for notifications.
4. 04If the usage is there, scope the app around the capability that justified it — not as a re-implementation of your whole website.
5. 05Keep the web version alive regardless. It stays your discovery surface, your shareable link, and your fallback for everyone who won't install anything.

The teams that regret building an app are rarely the ones who built the wrong thing technically. They're the ones who built a second product before the first had an audience, then had to fund both. Do it in the order above and the decision makes itself with evidence — which is a much better position than deciding it in a boardroom with none.

We build both, which is why we can be honest about which one you need. If you're weighing it up, tell us what the app has to do and we'll tell you frankly whether it needs to be an app.