An app is a distribution decision, not a design one
Most requests for an app describe something a website already does. The exception is narrow and it is about repeat use, not about looking modern.
Build a website unless customers will use the thing repeatedly and you need something only an installed application provides. An app adds two stores, two review processes, two release cycles and an install step between you and every new customer.
The cost nobody prices is the install
A website is one link away from any advert, message or search result. An app asks a stranger to visit a store, download, wait, and grant permissions before they have any evidence you are worth it. That gap removes most of the people who clicked.
For a first purchase, a booking or an enquiry, this is decisive. The app is not competing with your website on quality, it is competing with it on how many people arrive at the end.
What only an installed app can do
There is a real list and it is short: reliable push notifications, meaningful use with no connection, background location, deep access to device hardware, and a permanent icon on a screen the customer looks at daily.
If your answer to why you want an app is on that list, build one. If it is speed, appearance or a feeling of seriousness, those are website problems being solved with a much more expensive tool.
- Notifications you can rely on reaching the device
- Working properly with no connection at all
- Location updates while the app is not open
- Hardware access beyond what a browser is given
- Daily or weekly repeat use, by people who already chose you
Who the app is for
Apps earn their place with existing customers rather than new ones. A logistics client checking shipments daily, a restaurant's regulars, a member with a subscription: these are people who have already decided, and for whom the install is a small price with an obvious return.
That suggests an order. Win the customer on the web, then offer the app as the faster route for people who come back, and let install rates tell you whether the audience was real.
The recurring cost of two more platforms
An app is not shipped once. Each operating system releases a version every year, requirements change, certificates expire, and a release waits on review before customers can have it. That is a permanent commitment on two platforms in addition to the website you still need.
A team that can maintain one product well often cannot maintain three, and the website is usually the one that quietly stops being updated.
What to take from this
- 01The install step removes most first-time visitors
- 02Only build when you need notifications, offline use or hardware access
- 03Apps pay off with repeat customers, not with acquisition
- 04Two app platforms are a permanent commitment on top of the site
Ask the question directly
- Can a website send notifications now?
- On most platforms yes, once the visitor grants permission, and support has improved considerably. Delivery is still less predictable than a native app, so treat it as useful rather than guaranteed.
- Is one codebase for both platforms cheaper?
- It reduces development, not operations. Review, releases, store listings, device testing and yearly platform changes remain, and those are the recurring half of the cost.
- Our competitor has an app. Does that matter?
- Only if their customers use it. An app with few active users is a maintenance obligation with a logo, and it is worth checking review counts and update history before treating it as a threat.
Related answers
Web development
New builds, rescues and re-platforms, measured against what the site earns rather than against how it looks. The brand system that carries it is built in the same engagement.
Growth transformation
Organic accounts, reputation, lifecycle and conversion run as one programme, with fractional leadership above it for the companies that need the seniority before they can justify the salary.
Bring the decision you are stuck on
A call, forty five minutes, no deck. We will tell you if we are the wrong firm.