There is a moment in almost every project when the question appears: “should we build an app as well?” An app still looks like proof that a business has made it to the next level, the badge of a company that is serious now. But an app is not a medal: it is a tool. And like any tool, it only makes sense when there is a job it does better than anything else.

Native apps genuinely add things a browser cannot: on-device notifications, offline operation, closer access to the hardware, an icon on the home screen. They also come with a bill almost nobody budgets: constant maintenance, two stores, review queues and compatibility with environments that change without asking. The right question is never whether apps are fashionable — it is whether a real use justifies the cost.

This guide separates what an app actually adds from what it merely promises, shows what a modern responsive website — PWA included — already covers, and leaves you a small framework for deciding without inflating a project on image. No figures, no magic answers: honest questions and judgement.

01Quick Summary

  • What it really addsOn-device notifications, offline use, deeper hardware access and a home-screen presence: that is the genuine native value, and there are only four items on the list.
  • The distribution mythNobody searches the app store for a local service or a garage: the store is a destination, not an entry door. You bring people to your app from elsewhere.
  • The real costVersion one is the cheap part. Compatibility, updates and reviews across two stores are the recurring bill — and an abandoned app hurts your brand publicly.
  • A website often sufficesBeing found, informing, booking, capturing leads and selling: a well-built responsive site covers most small-business cases without an app.
  • The PWA middle groundAn installable site with an icon, fast loads, some offline content and web notifications: app-like behaviour without the store overhead.
  • When the answer is yesA frequent daily habit, a decisive native capability, or solid internal use. If none of those hold, there is no case, however nice the launch screenshot looks.

02What an App Really Adds (and What It Only Promises)

Start with the genuine article, because four capabilities do set a native app apart from the browser. First, push notifications on the device: they arrive even when the person is nowhere near your website, and they open a direct path back into the product. Second, offline operation: data cached on the phone keeps working without coverage, which matters for field workers, travellers and anyone in areas with poor signal. Third, the hardware: deeper camera and sensor access, legitimate background activity, system payment components. And fourth, home-screen presence: an icon one tap away acts as memory and habit — but only if the product gets opened often.

Distribution: what the stores give you — and what they don’t

The other supposed advantage, being discoverable in the store, works far worse than it sounds. People do not search app stores for a local service, a neighbourhood clinic or a garage: they search a general search engine, and that is where a website appears first. Stores have genuine discovery in a handful of consumer categories people actively shop for. Everywhere else, installs do not come from store browsing — they come from traffic you send yourself: your website, your social posts, a QR code on the counter. An app is not an entry channel. It is a destination, and somebody has to escort people to it.

03The Real Cost: Version One Is the Cheap Part

When an app is budgeted, you pay for the visible part: screens, design, development, launch. The part that breaks decisions is invisible: continuity. An app lives inside two ecosystems — operating systems and store policies — that change without warning. Every year you update compatibility, recompile, adapt to new privacy permissions and pass review again. A new OS version can leave your app installable but unusable, and nobody will give you advance notice: you find out through the ratings.

The bill of two platforms

If your audience lives on iOS and Android, the product has two codebases, two review queues, two sets of rules and double work on every meaningful change. And behind all of it stands whoever maintains it. If version one was a one-off contract with no continuity plan, the app becomes public debt: an app with bad ratings or crashes on the latest phone tells your story worse than having no app at all. It documents, in public, a product you abandoned.

04When a Responsive Website — or a PWA — Is Enough

For most small-business cases, a website does the whole job: being found, loading fast on mobile, informing, taking bookings, capturing contacts and selling. A site built properly, with its own design and a structure meant to convert — the point made in the benefits of a custom website — needs no app behind it to close customers. Selling online works in the browser too: an online store with catalogue, checkout and shipping is a web experience by definition, and nobody expects to install anything to buy once a month.

PWA: app behaviour without the stores

There is also a middle ground that has matured a lot: a PWA is a website installable from the browser, with a home-screen icon, fast loads, some content available offline and — depending on the platform — push notifications without any app store involved. It does not match a native app where heavy background use or deep hardware access is required; the browser still has limits. But for a service business, a shop with bookings or a local store, a PWA delivers what people actually use from apps: quick access, a saved screen, and alerts if they opt in. All of it on one codebase you update once, and everyone has it immediately.

05When an App Is Worth It (and How to Decide)

The profile of cases that justify an app is recognisable: consumer products with frequent daily use, where the home-screen icon builds a habit; experiences that depend on offline operation or heavy hardware use; loyalty programmes opened several times a week; digital products whose primary consumption happens on a phone. Notice the pattern: an app is justified by a habit it serves, not by the image of the company that shows it off. No habit, no case — however reasonable the launch budget seems.

The quiet case: internal use

One scenario flips the general rule in an app’s favour: software for your own team — warehouse scans, technicians on the road, work tickets, checklists, field visit logs. Nobody will find you in a store because your users are already inside the company, and the tool can be distributed without a public review queue. Frequency of use, robustness and offline reliability decide here, and that is native territory where an app clearly beats a web page. Far more often than marketing admits, a well-built internal tool saves more hours per week than any public app ever would.

The four questions that decide

Before approving an app, answer four uncomfortable ones: how often will a customer realistically open it — is there a habit or just a launch photo? Which native capability is decisive, and could the browser genuinely not get close? Who will maintain it for the next three years, on what budget? And what happens if nobody installs it? If the answers do not hold, a website on the right stack will be cheaper, easier to maintain and easier to find. If they hold, the app stops being a vanity project and becomes an investment with an owner. When the answer is the website, that job — fast, findable, built to convert — is exactly what custom WordPress development takes on: one codebase, updates visible to everyone the moment they ship.

06Frequently Asked Questions

Is an app better than a website for being found?

No: the website is the surface search engines index and rank, and with no site there is nothing to rank. An app complements a website when there is a real habit behind it; it never replaces it as the entry channel. If nobody finds you on Google, nobody will install you either.

Is a PWA a real app?

It is something else: a website you can install from the browser, with a home-screen icon, fast loads and some content available offline. It does not fully cover heavy background use or deep hardware access. Its practical advantage is delivering what people actually use an app for — quick access and notifications if they opt in — without maintaining store builds.

We only want to send notifications. Do we need an app?

Not necessarily: websites can send push notifications too, with the user’s permission and within each platform’s limits. If notifications are the only reason to build an app, test the web-based version first before paying for app development and ongoing store maintenance.

What happens if nobody uses the app after a few years?

It decays: it breaks compatibility, collects bad ratings or disappears from the stores, and the public record shows you abandoned a product people trusted. Publish an app only with a clear continuity plan and a named owner. Without that plan, a maintained website beats a dead app.