App or website: what does my business really need?

"We need an app" is a sentence I often hear in a first conversation. Sometimes it's true. Often, though, there's a different wish behind it: customers should order faster, staff should record something on the go, or the business should look more modern. For many of these goals, a good website or web application is the better choice. Here I explain how to tell the difference.

The four options at a glance

1. 01

   Classic website

   Runs in the browser on any device, is found by Google, needs no installation. Ideal for informing and being found, receiving enquiries or taking bookings and orders.

2. 02

   Progressive web app (PWA)

   A web application that behaves like an app: it can be added to the home screen, opens full-screen and partly works offline. It's distributed without an app store, simply via a link.

3. 03

   Native app

   One app for iOS and one for Android, each built with the platform's own tools. Full access to all device features and the best performance, but two codebases and therefore more effort.

4. 04

   Cross-platform app

   One codebase that produces apps for iOS and Android, for example with React Native or Flutter. For most business apps a good compromise between effort and capability.

When a website or PWA is enough

First ask yourself: how often does a customer use it? Someone who orders or books with you once a month is reluctant to install an app for that. A link, a QR code or a Google search result is the shorter path here. The ordering system I built for the EFA bistros, for example, deliberately runs in the browser: guests scan the code and order without installing anything.

• Your customers come occasionally, not daily.
• You want to be found on Google.
• The features are forms, lists, orders, bookings, documents.
• You want to publish changes immediately, without an app store review.
• The budget should go into content and processes, not into two platforms.

A PWA can do quite a lot by now: camera, location, offline storage and, on many devices, push notifications. There are limitations on iPhones, though; for push notifications, for example, the PWA has to be added to the home screen first. That's something to test before deciding rather than assume.

When a real app makes sense

• The application is used daily or several times a week, for example by your staff or regular customers.
• You need device features that aren't available in the browser or only in limited form, such as Bluetooth devices, background location or certain sensors.
• The app must work reliably offline, for example on building sites or in a warehouse without signal.
• Push notifications are central to the value, on iPhones too.
• Visibility in the app store matters for your business model.

For internal apps used only by your team, there are also ways to distribute them without a public store listing. That saves review time and keeps the app out of public view.

What drives the effort

Quoting concrete prices without a project description wouldn't be serious. But I can tell you which factors determine the effort, whether website or app:

• Number of platforms: web only, web plus one app, or web plus iOS and Android.
• User accounts and roles: who may see and do what?
• Connections to other systems such as tills, inventory, accounting or payment providers.
• Offline capability and synchronisation, one of the most complex parts.
• An admin area where you maintain content and data yourself.
• Publishing and maintenance in the app stores, including updates for new operating system versions.
• Running costs: hosting, developer accounts with Apple and Google, maintenance.

The last point in particular is often forgotten. An app isn't finished after launch. New iOS and Android versions come out every year, and the stores require apps to be adapted to current rules. Plan for that from the start.

My approach: web first, app when needed

In many projects I recommend starting with a web application or PWA. It goes live faster, is easy to change and shows which features are actually used. If it then turns out that a native app adds real value, it can build on the same foundation: server, database and interfaces stay, only the user interface is added. That way you spend money on the app only once you know it's needed.

There are also cases where it's clear from the start that it has to be an app, for example a field-service app that works offline. Then it's more honest to plan it that way from day one.

Questions for your decision

• Who uses the application, and how often?
• What exactly should the user get done with it, in one sentence?
• Does it have to work without internet?
• Which device features are really necessary?
• Who maintains content and data after launch?

More notes

• A website in Germany: what Turkish business owners should know6 min read
• Getting an app built: process, cost drivers, and web app or native app6 min read
• Custom software or off-the-shelf: when your own software pays off6 min read