Should you build an app or a website first?

"I want an app" is how roughly four out of five first conversations begin. Sometimes that is right. More often, for a first version, a website gets there faster and finds out more.

The case for a website first

• Nothing to install. An app asks for a download before it has proved it is worth anything. Most people say no, and you never learn why.
• One build, every device. No iOS and Android split, no separate testing.
• You can ship on a Tuesday. No review queue between you and a fix.
• Google can find it. App stores are not a discovery channel for a business nobody is searching for yet.
• It can be sent as a link. Which matters enormously if your customers arrive from Instagram or WhatsApp.

When an app is genuinely the right call

There is a real test, and it is short. You need an app when the thing you are building depends on something only an app can do:

• It has to work without a network connection — a driver in a dead zone, a field technician in a basement.
• It needs push notifications people will genuinely act on. Not marketing pushes; operational ones.
• It needs continuous access to the camera, GPS or Bluetooth while running in the background.
• People use it every day, for years, and the icon on the home screen is doing real work.

If none of those are true, an app is usually a more expensive route to the same place.

The middle option nobody mentions

A well-built website can be installed to a phone's home screen, run full-screen without a browser bar, and work offline for read-only content. For a lot of businesses this covers everything they actually wanted from "an app", at the cost of a website. It is worth ten minutes of the first call.

A concrete sequence

1. Build the website version. Get real people using it.
2. Watch what they do on phones specifically, and where they drop off.
3. If the thing standing between you and growth is genuinely a native capability, build the app then — with a year of real usage data telling you exactly which screens matter.

That order is cheaper, faster, and produces a better app at the end of it than starting with the app would have.

What an app costs that a website does not

The build itself is only part of it. An app brings a set of ongoing obligations that a website simply does not have, and they are rarely in the first conversation.

• Two platforms. Even sharing a codebase, iOS and Android differ in permissions, notifications, background behaviour and review rules. Testing is doubled.
• Store accounts and fees. Apple charges yearly, Google once. Both must be in your name, not your developer's — this matters enormously if you ever change developer.
• Review queues. A fix is not live when you press publish. It is live when a reviewer approves it, which can be hours or days, and can be rejected for reasons that surprise you.
• Users on old versions. People do not update. Your server has to keep speaking to a version of the app from eight months ago, or you have to force upgrades, which loses users.
• OS updates. Both platforms change things yearly. An app left alone for two years often will not build, let alone run.

None of this is a reason to avoid apps. It is a reason to be sure you need one, because these costs continue long after the build is paid for.

The store part nobody warns you about

First submissions get rejected routinely, and usually for something unrelated to the app's quality: a missing privacy policy, a login screen with no way to try the app, a permission whose justification was not written clearly enough, or an account-deletion route that must exist inside the app.

Budget a week for the first submission and do not schedule a launch event on the assumption it appears on a particular day. This is the single most common cause of a missed launch date on mobile projects, and it is entirely predictable, which makes missing it avoidable.

What “install to home screen” actually gets you

A well-built website can be added to a phone's home screen, open full-screen without browser chrome, cache content so it opens offline, and — on Android reliably, on iOS with caveats — send push notifications.

What it still cannot do well: run in the background, use Bluetooth or the sensors freely, or appear in an app store where people look for things. If none of those matter to you, this route gives most of what people mean by “an app” at the cost of a website, with no review queue between you and a fix.

Ask what specifically you need that only an app can do. If the answer is “it feels more serious”, that is a design problem, not a platform one.

The order I would actually recommend

Website first, in almost every case. Get real people using it and watch where they struggle on a phone. Then, if what stands between you and growth is genuinely a native capability, build the app — with a year of usage data telling you exactly which three screens matter.

The apps built that way are smaller, better and cheaper than the ones built first, because they are built from evidence instead of from guesses about what people would want.