Do You Need An App, Or Just A Website?

I build mobile apps. I'd rather you didn't buy one from me unless you need it, and most local businesses don't, so this post is mostly me arguing against my own more expensive product.

That's not modesty. It's that an app you don't need is worse than no app at all — it's money spent on a thing nobody installs, and it sits in a store looking neglected, which is a worse signal than not being there.

Here's how I'd decide.

The three decisions an app has to win

A website has to be opened. That's it. Somebody taps a link or a search result, and they're in.

An app has to be found, then installed, then kept. Find it in a store with millions of other things in it. Choose to give up storage on a phone that's already telling them it's full. And then not delete it in the next cleanout.

That's three separate decisions you have to win before your app has done a single useful thing, versus one for a website. That gap is the whole argument, and no amount of good design closes it. It's why an app is a bad fit for anyone whose customer interacts with them occasionally, and a good fit for anyone whose customer interacts with them constantly.

What I did with my own business

CageList is a marketplace for booking batting cages. I built it, I run it, and it's a website, not an app. That was a deliberate choice and I'd make it again.

The reason is the shape of the use. A player books a cage, maybe a few times a month. If booking required installing something first, a meaningful number of those people would simply not book — not because they didn't want the cage, but because there was an install between them and the cage. A link in a text message gets opened. An App Store page gets bounced off.

If I ever build a version for facility owners to run their day from — the people who are in it every single morning, checking today's bookings — that's a much better case for an app, because the habit is already there. The install is a one-time cost against daily use. That's the trade that works.

Signs you actually want an app

People use it several times a week. A habit survives an install. An errand does not. If your customer's relationship with you is "twice a year when something breaks," the app will be deleted before the second time.

It has to work with no signal. A warehouse, a basement, a field, a job site out past where the bars run out. A website needs a connection. An app can hold the data on the device and sync later. If this is your situation, it's not a preference, it's a requirement, and it's the strongest reason on this list.

It needs the phone's own hardware as part of the job. Not "we could use the camera" — actually needs it. Scanning something, measuring something, tracking a route, taking photos in a specific way at a specific moment in a workflow.

A notification has to arrive on a lock screen. If the thing you're sending is time-sensitive to the minute, an email that sits unread for four hours is not a substitute. Text messages are the cheaper answer to this one and often the right one, so ask whether a text would do before concluding it wouldn't.

Your staff live in it. Internal tools are the most under-appreciated case for an app. Nobody has to be convinced to install the thing their job runs on, which removes the hardest of the three decisions entirely.

Signs it's a website

Somebody's deciding whether to use you at all. Every part of that decision happens before they'd ever install anything. Ask someone to install an app to find out your prices and you've lost them.

You want to be found. This is the big one, and it is the entire job of a website written for your kind of business. Apps are found by people who already know your name. Websites are found by people who don't, which is the entire point of search, maps and local listings. An app has no route in from a stranger. If your problem is that not enough people know you exist, an app does not touch that problem.

The main job is showing information. Hours, prices, services, photos, a phone number, a form. All of that is a website's home ground.

There's one project's worth of money. Then it's a website, and the packages start at fifteen hundred dollars, because an app needs a website anyway — to be discovered from, to explain itself, and to serve everyone who won't install it. Building the app first means building the second thing first.

What building an app actually involves

If you've read this far and you're still in the yes column, here's what you're signing up for, so none of it is a surprise later.

Two platforms. iPhone and Android are different systems with different rules, and while I build one app that runs on both, "runs on both" still means testing on both and dealing with both stores.

Two review processes. Apple and Google both look at what gets submitted before it goes live, and both reject things. Sometimes for a good reason, sometimes for a reason that takes a round of back-and-forth to understand. That's days, not minutes, and it happens on every meaningful update — which is the part that surprises people most. A website change is live in about a minute. An app change is live when someone else says so.

Accounts in your name. Both stores require a developer account, and that account should belong to your business, not to me. It's an annual fee on Apple's side and a one-off on Google's, both small, both yours. This matters far more than it sounds like it does — an app published under a developer's personal account is an app you don't really own.

And underneath it, the same back end the web version uses, so there's one set of data and not two drifting apart.

The short version

Most local businesses need a website that works properly on a phone, which is a different and much cheaper thing than an app. Some businesses genuinely need an app, and for those the case is usually obvious once you apply the offline test or the several-times-a-week test.

If you're not sure which one you are, tell me what you're trying to do and I'll tell you straight. If it's a website, I'll say so, and I'll charge you less.