App or mobile website? Read this before you spend the budget
A competitor launched an app, and now it feels like you're falling behind without one. But that's the wrong question — the real one is how a customer finds you, and why they come back.
Those two questions have different answers for different businesses: some need nothing more than a fast mobile site, others genuinely need an app. The wrong call doesn't show up in month one — it shows up around month six, when installs have flatlined but the server bill, the updates and the cost of running two app-store listings keep going. This piece is here to help you frame that call before you ask anyone for a quote.
Websites are for discovery, apps are for habit
Someone facing a task for the first time opens a search, compares options in a browser, and picks one. That's what a website is for — an entry point with no friction. An app works the other way round: only someone who has already decided, and already knows you, installs it. That's why airline, bank and taxi apps work — people open them several times a week, and that frequency is what pays back the install.
If your business runs on one-off search and one-off purchase — choosing a restaurant, a single service, comparing options — the customer finds you on Google, decides on the site, and leaves. Asking them to install an app first is an extra step, and every extra step loses part of the audience along the way. The question isn't whether the app would look good — it's whether the customer thinks the install is worth it, and those are two different questions.
The install barrier: why a "great idea" doesn't get downloaded
A website link and an app link behave differently. Click a website link and the page opens. Click an app link and you're routed to a store, an "Install" button, a storage prompt, then the launch, then maybe a sign-up. Each step is a decision point, and at every decision point some people drop off.
That matters most for traffic coming from ads. Someone who has just seen an ad is interested "right now" — asking them to install first and look later kills that interest on the spot. A website answers the same impulse without losing it: it opens in seconds, and there's no install step at all. A visitor who lands straight on the answer from an Instagram or Google ad almost always converts better than one first routed through an app store.
The reverse is also true: for a customer who already knows you and comes back often, an app isn't a barrier, it's a convenience — install once, then open with one tap. That convenience only pays off when repeat use is genuinely frequent.
The real cost: two platforms, two release cycles, ongoing spend
An "app" isn't a one-time cost — it opens a line item and keeps it open.
During development
iOS and Android are different platforms. Covering both means either writing two separate apps or choosing a shared-codebase approach that outputs both. Either way it needs more test scenarios, more device variants, and every release passes through each store's own review before it reaches a user — meaning the release date isn't entirely yours to set.
During maintenance
A website update reaches every visitor the moment it ships. An app update doesn't — some users never update at all, so support means keeping two (sometimes three) versions working at once. Every operating-system update forces an adjustment on your side too, or the first support call will be "it won't open." That's not a one-time line in a proposal — it's a line that renews every year.
None of this means "don't build an app" — it means the real price of an app isn't the number in the first proposal, it's the total you'll have paid by the end of year one.
The middle path: progressive web apps
Between a fully native app and a plain website there's a third option — a progressive web app (PWA). It runs in the browser, but a user can add it to their home screen, and on some platforms it supports offline caching and push notifications. The upside is clear: one codebase, no store review, and updates go live as instantly as a website's do. There's a real limit too: access to the camera, GPS and notifications varies by platform, so it needs checking project by project. For high-frequency use that doesn't need everything a device can offer, a PWA often lands right in the middle.
Where an app genuinely wins
For some business models, the answer is clear:
- Frequency is high. The customer deals with you several times a week — delivery, banking, fitness tracking, anything used daily.
- You need what the device itself offers. Camera, GPS, offline access, push notifications — a browser can't fully match these.
- The notification is the product. Order status, a queue alert, a personal discount — you initiate the return visit instead of waiting for the customer to remember.
- Loyalty already exists.
If none of those four are true, a fast, mobile-friendly website with simple navigation does the same job for less money and reaches more people doing it.
An app rewards loyalty a customer has already earned; a website earns the loyalty they haven't given yet — get the order wrong and you waste both.
Questions to answer before you commit
Ask yourself these four questions before you request a build quote, not after:
- How many times a month does an average customer look for me — once, or ten times?
- Would my service actually break without the device's camera, GPS or push notifications?
- How much of my current enquiry volume would I lose along the way by adding an install step?
- Who is budgeting, a year from now, to keep two platforms updated?
If the answers point to "yes," an app is a reasonable call. If they point to "no" or "not sure," starting with a fast mobile site is the safer move — the decision can be revisited once real usage data exists. An app built on a guess, only to discover the customer never wanted it, is the most expensive way to learn how cheap it would have been to ask this question first.
If it's hard to answer these on your own, our mobile app development service exists to work through them with you — before the budget number, not after it.
