A mobile app or a responsive site: the question behind the question

Ask what the customer must be able to do, not which artefact to commission. If the work happens in a shop, a warehouse or a home with unreliable signal, or depends on a notification arriving while the app is closed, an installed application earns its cost. If the work is browsing, ordering, booking or reading, a responsive site does the same job for less money and reaches people who will never install anything. Most business requests start as the second case and get described as the first.

What does an installed app actually enable?

Four things matter. Everything else is polish, not capability.

A reliable presence on the device. The icon is on the home screen, the data is cached, and the first screen opens without a network round trip. A website can cache too, but a browser may evict that cache under pressure, and the user cannot tell.

Notifications that arrive when the app is closed. Web push exists and works on Android; on iOS it is more limited, and depends on the site being installed and permission granted twice. If a driver must learn about a changed delivery address while the phone is in a pocket, an installed app does it predictably.

Device credentials as the login. A biometric check that unlocks a key held in the device's secure hardware is a different posture from a password typed into a browser. For a field team sharing devices, that difference is the point.

Background work. Reading barcodes, uploading photos as they are taken, syncing a queue of orders when signal returns — an installed app tolerates interruption in ways a browser tab does not.

Note what is not on the list: speed. A well-built responsive site feels fast on a decent connection, and an app calling a slow server on launch feels slow; speed is an engineering property, not a delivery format.

What does the app cost that the quote does not show?

The build is the visible cost. The continuing costs decide whether the app is still usable in three years.

• Two codebases, kept in step. If you also have a website — and most businesses do — every price change and every new field exists twice. Two places to change, two places to forget.
• Store review as a permanent constraint. Every release passes through a review whose timing and rules you do not control. A fix for a wrong price on Monday may not reach users on Monday. Keep the parts that change often on the server.
• Devices you must support. Screen sizes, system versions, and phones that stopped receiving updates years ago but are still in use. That long tail is where layouts break.
• Installation as a filter. A store search, a download, a permission prompt and an account are four chances to lose a customer who would have ordered in one tap.

Capability	Responsive site	Installed app
Works with no signal	Partial, cache-dependent	Yes, by design
Notification when closed	Limited, especially on iOS	Reliable
Biometric login	Not available	Yes, via device key
Time to first use	One tap	Install and permissions

When is a responsive site the honest answer?

When the job is information or a transaction, and it must work for everyone who arrives. A boutique publishing a catalogue, a pharmacy taking reservations, a clinic letting patients book a slot — these are content problems with a transaction attached. A website serves them without an install step, without store rules, and with one place to correct a mistake.

A responsive site also fails more gracefully. A wrong price is a deploy, not a review queue. A new language is a route, not a second binary. Analytics show which page people abandoned instead of which screen.

The responsive web design basics on web.dev cover the mechanics: viewport, flexible grids, breakpoints chosen from content rather than device names. Getting those right is most of the difference between a site that feels native on a phone and one that feels like a shrunken desktop.

Can you have both without building twice?

Yes, and it is usually the right shape for a business with one product and two audiences. Build the responsive site as the product, then add a thin installed shell around the same server interface for the people who need device capabilities. Rules, prices and permissions stay in one place; only delivery differs.

This works while the app is a client of a documented interface, and breaks when it carries business logic of its own. The test is simple: when a price changes, how many systems must be redeployed? One is fine. Three is a bill you pay every month.

A decision procedure

1. Write the one job the user must complete, with the place and conditions. "A driver confirms delivery from a van in a wilaya with patchy signal" is a different sentence from "a customer checks whether the shop is open".
2. Test the four capabilities honestly. If none is required, the website is the answer.
3. Decide whether notifications are essential or merely convenient. Convenient notifications do not justify an app; a missed delivery does.
4. Count the places the rules will change. If prices or stock change weekly, keep them on the server and version the app, or accept a permanent delay.
5. Price three years, not the launch. Build, store fees, device testing, the second codebase — against the website plus the workaround the app replaces.
6. Ship the smallest version that proves the need. One job, one screen, real users, before the second feature exists.

Where this goes wrong

• The app is a brochure. A web view around the same pages, with an install step and a review queue added. It costs more and behaves worse than the site it wraps.
• Offline is claimed and not tested. Offline means conflict rules: what happens when two devices edit the same order and both sync. Teams discover this in the field, not in the demo.
• Notifications become noise. An app that notifies about everything is muted within a week, including the one notification that mattered.
• The website is abandoned once the app ships. Customers who will not install anything still arrive from search and find a page nobody has updated since launch.
• Store rejection is treated as a bug. It is a constraint of the channel and belongs in the plan as a recurring cost.

What this does not cover

This compares delivery formats, not product strategy: it does not judge whether the product is worth building, and assumes a back end either way. It says nothing about hardware integrations — printing, scanning, card readers, Bluetooth scales — where the answer is usually an app and the detail depends on the device. Store policies and fees change; check the current rules rather than a figure in an article.

We build the responsive site first and the installed app only where a device capability is the reason for it.