Website, web app or mobile app: how to choose before you spend a rand
Most businesses ask for an app when they need a web app, or build a web app when a good website would have done. A decision framework based on what your users actually need to do, and how often.
Dilshaad WilliamsDigital Entrepreneur & AI Consultant 6 min read
"We need an app" is often the first sentence of a project and the least examined. An app in the app store is a specific tool with specific costs, and it is the right answer less often than people expect. Choosing wrong does not just waste the build budget. It commits you to years of the wrong maintenance.
The useful question is not "what do we want to build?". It is "what does a user need to do, how often, and where?". The answer usually points clearly at one of three things.
A website: when people need to find, understand and contact you
If the job is to explain what you do, prove you are credible, and turn a visitor into an enquiry or a sale, you need a website, and you need it to be excellent. It is discoverable through search, shareable by link, needs no install, and is the cheapest thing to change. Most service businesses stop here, and should.
A web app: when people need to do something, repeatedly, on any device
Booking, quoting, client portals, dashboards, internal tools, anything with a login and data that changes. A web app runs in the browser, works on every device from one codebase, and can be installed to the home screen as a progressive web app so it feels native. No app store review, no forced updates, one thing to maintain. This is the right answer for most business tools and most client-facing systems.
A mobile app: when the phone itself is the product
- You need hardware the browser cannot fully reach: background location, Bluetooth devices, camera-heavy workflows, reliable push on iOS.
- Users will open it many times a week and the home-screen icon is part of the habit.
- Offline use is essential, not a nice-to-have.
- Being in the app store is itself a distribution channel for your audience.
If two or more of those are true, build the app. If none are, you are paying for two codebases, two store submissions and ongoing platform changes to get something a web app would have delivered faster.
A sequence that de-risks everything
- 01Write down the three things a user must be able to do. If you cannot, you are not ready to build anything.
- 02Prototype the flow on paper or in a clickable mock-up and put it in front of five real users. This costs almost nothing and changes most projects.
- 03Build the smallest version that does those three things well, usually as a web app.
- 04Measure usage for a quarter. Let real behaviour, not the original brief, decide whether native is worth it.
The best app isn’t the most complex one. It’s the one your clients and team use every day without thinking about it.
Want this applied to your situation?
Introductory conversations are held via Microsoft Teams, with no pitch decks and no pressure. If you'd rather read more first, the App Development page explains how I work.