This is probably the question I get asked most often. And the honest answer is: it depends on who you’ve been talking to before you ask.
App developers will tell you that you need an app. Web developers will tell you that you need a website. Both of them are right, for the work they do. But neither of them has a strong incentive to tell you that you might not need what they’re selling, or that there’s a third option worth considering first.
So let me try to answer this without a skin in the game.
Website or web application? The distinction that matters
First, a distinction that matters more than most people realise.
When someone says “website,” they usually mean a web application. A website, strictly speaking, presents information: it’s something you read. A web application does things. It carries out tasks. It behaves like software. Most businesses asking the app-versus-website question actually need a web application. They just don’t know that’s what it’s called.
This matters because once you understand that distinction, the question shifts. It’s no longer “app or website?” It becomes: “native mobile application, or web application that works across all devices?”
Why a responsive web application is usually the right start
My personal position (and I hold it with appropriate humility) is that a well-built responsive web application can go very far in solving both requirements. One solution. All devices. Browser-based. No stores involved.
It’s harder than I make it sound. Done properly, it requires real design rigour from the beginning: you can’t retrofit a mobile experience onto something designed for desktop and call it responsive. But it is achievable, and for most businesses, it’s the right starting point.
Native mobile apps, the kind you download from the App Store or Google Play, are genuinely the right answer in some situations. Just fewer situations than the market suggests.
When a native app actually makes sense
So when does a native app actually make sense?
In my experience, the clearest justification is when you genuinely need access to on-device capabilities. Camera. Microphone. GPS at a granular level. These things are technically possible in a web application, but meaningfully easier to implement and more reliable in a native app. On-device security is also stronger: the application and its data live on the device rather than being accessed through a browser.
Outside of those scenarios, the argument for native gets thinner quickly.
I think I need an app, versus I know I need an app
Here’s how I’d describe the conversation that happens in my office.
Someone comes in saying they need an app. We talk through what it needs to do. And within a fairly short time, one of two things becomes clear: either they think they need an app, or they actually know they need an app.
“I think I need an app” usually means: everyone has apps, our competitors have an app, it feels like the right thing to do. That conversation leads somewhere different.
“I actually know I need an app” usually means: our users need to use the camera, or we need offline functionality, or we have a very specific reason why a browser-based solution won’t work. That conversation leads to a native build, with eyes open about what it involves.
What going native actually involves
And what does it involve?
The two major app stores, Apple’s App Store and Google Play, sit between you and your customers. You cannot deploy a native app without going through them. They have approval processes. They take a percentage of any revenue generated through the app. They can reject updates, require changes, and operate on their own timelines.
This isn’t entirely a bad thing. There’s a quality filter built in, and distribution through the stores has real advantages. But it’s a layer of control that many businesses don’t fully account for when they decide they want an app. Could work in your favour. Could work against you. Either way, you can’t opt out of it.
If you’re building a responsive web application
If you’ve worked through all of this and a responsive web application is the right direction, here’s what to know going in.
Design it properly from the beginning. Mobile experience can’t be an afterthought. It has to be designed in from day one. And if you need any specific on-device functionality (camera access, microphone, anything that touches the hardware), do a technical proof of concept before you commit to the full build.
A proof of concept is quick. It’s cheap relative to the cost of the full project. And it answers the most important question early: can this actually be done the way we’re imagining, or do we need to rethink the approach? It’s a go/no-go mechanism that most businesses skip. And then discover they needed it six months into a build that isn’t working the way they expected.
The real question to answer first
The question isn’t really “app or website.” It’s: what do my users actually need to be able to do, and what’s the simplest, most reliable way to let them do it?
Answer that honestly (without a vendor in the room telling you what they’d like to build) and the right answer usually becomes clear.
Garth Shoebridge has been helping South African businesses make digital decisions for 25 years, including the ones that happen before anyone gets a quote. If you’re trying to work out what you actually need before you brief anyone, start with a conversation.