Mobile App or Mobile Site?

The request usually arrives fully formed. Someone raises it at a leadership meeting, the room nods, and by the time it reaches a developer it has a budget line and a rough launch quarter attached. What it does not have is the one sentence that matters...what the app does that the website cannot.

That one sentence is the entire decision, and it is usually missing. Asked for it, most people describe a booking form, a loyalty card, a menu, a catalog, an order status lookup, or a faster way to reach a human. Every one of those is a web page. A small number of businesses describe something else, and those are the ones that should genuinely build an app...here is how I tell the two apart.

The One Sentence Test

Ask the owner to finish this sentence out loud, in front of whoever asked for the app. Our customer uses the app to do X, and the website cannot do it because Y. When the Y half comes back as "the site is slow on a phone" or "nobody can find the booking page," the conversation is not about an app at all...it is about a website that fails on a phone, and rebuilding that as an app costs many times what fixing it costs.

It is the fastest way to separate a platform decision from a frustration. The frustration is almost always legitimate...the proposed fix is just the wrong size. Nobody sets out to rebuild a slow page as an app...they set out to fix something that genuinely is not working.

Does the Value Need Hardware?

An app earns its place when the core experience needs something that belongs to the phone rather than to the page...not a feature you could bolt on later, but the material the product is actually made of.

• Camera Work: Scanning, measuring, or documenting a job out in the field.
• Background Location: Routing, arrival detection, tracking a crew or a delivery.
• Hardware Pairing: Bluetooth to a lock, a sensor, a reader, equipment you sell or service.
• Offline Use: A basement or a site past cell coverage, with work still to finish.
• Critical Alerts: Notifications that have to be reliable and time critical, not marketing blasts.

Browsers handle more of this than most people asking for an app assume. A web page can use the camera, cache itself so it opens without a connection, and on current platforms send push notifications once the site has been installed to the home screen. So the real question is not whether the capability exists...it is whether the work leans on it hard enough that browser support becomes the constraint. Most of the time it does not...which is worth knowing before the estimate arrives.

How Often Do They Return?

A home screen is scarce real estate and people defend it...an icon has to earn its square by being opened regularly. Frequency per person (not volume for the business) is the measure.

A fitness studio whose members show up several times a week has a case. The same goes for a service business whose customers check an active job, a route and/or an account balance on a weekly rhythm. A roofer can serve hundreds of households in a strong year and still see almost no repeat opens...each customer needs a roof once and then not again for a long time.

The number that decides it is how many times one individual customer will open this in a year. It is not a hard number to estimate. If it comes back small, the app gets installed during a promotion and then ignored...gone the next time the phone runs low on storage.

The Year Three Ownership Question

Websites decay gently...a neglected site looks dated and slowly loses ground. Apps break hard. Operating systems change, store policies change, the libraries the app was built on stop being maintained, and one day the thing simply will not launch on a new phone. There is no partial credit.

So three names belong on paper before anyone writes code. One person fixes it, one funds the fixing, and one has the authority to retire it. If those names do not exist, the answer is no...no matter how good the idea is. What has to be funded every year, and not just at launch:

• Platform Churn: Compatibility work as each operating system ships a new version.
• Store Overhead: Accounts, review submissions, and policy changes nobody asked for.
• Backend Upkeep: A second system sitting behind the app, with its own bills and its own maintenance.
• Login Support: Customers who cannot get in and need a person to help them.
• Two Codebases: Both major platforms, or a cross platform framework with its own upgrade cycle.

What the Mobile Site Fixes

When the three answers point away from an app, the work that actually moves the needle is unglamorous. None of it makes for a good launch announcement...all of it shows up in whether the phone rings.

• Load Speed: How the site behaves on a mid-range phone over a cell connection.
• Thumb Forms: Fields someone can finish one handed, standing in a parking lot.
• Contact Access: Tap to call and tap for directions, visible without any scrolling.
• Real Availability: Something on the page more useful than an instruction to call us.
• Page Coverage: One page per service and location, findable by problem rather than by brand.

Nobody browses an app store to solve a local problem. Search engines and AI assistants read web pages, so the mobile site is where discovery happens, and where the app would have to be advertised anyway.

The Installable Web App Option

Between the two options sits one that most owners never get offered...the installable web app. It goes on the home screen, opens without a browser frame, caches enough to work on a poor connection, and can send notifications on current platforms. It runs on one codebase, skips store review, and stays findable in search.

It does not replace an app that needs deep hardware access...it covers much of what people mean when they say they want an icon on the phone.

What to Do Next

Take an hour and work through it in order.

1. Write the one sentence. If the because half cannot be finished without describing a website problem, stop there...the project is the website.
2. Run the three questions in order: device dependence, repeat frequency, year three ownership. Anything short of yes on all three means the mobile site is the project.
3. If the mobile site is the project, fix speed and the primary conversion path first, then give it a quarter and look at what changed in calls, forms and bookings.
4. If all three are yes, scope the smallest version that proves the core interaction, ship it on one platform, and name the maintenance owner before the first build starts.

Over the years the businesses I have watched regret an app almost never regret the idea itself...they regret the order...they built the full version before anyone knew whether one customer would open it twice.