The dividing line
A website presents information. Every visitor sees broadly the same thing, and the content changes when you decide to change it.
A web app holds state. People sign in, data is saved, and what you see depends on who you are and what you did last time.
That is the whole distinction, and it matters because the second one has permanent obligations: accounts, passwords, backups, access control, privacy law, and a support burden that never ends. The first one mostly does not.
Signals you need an app
- Anyone logs in
- Customers see their own records, orders or history
- Staff use it to do their job rather than to publish
- Data entered today must still be right in two years
- Two people can change the same thing at once
One of these is enough. They rarely appear alone.
The trap in the middle
Most briefs land in a grey zone — a website with a booking form, a members page, a quote calculator. The instinct is to bolt these onto a site, and that is often correct. It stops being correct the moment the bolted-on part becomes the thing customers actually use.
A useful test: if that feature broke on a Sunday, would you need it fixed before Monday? If yes, it is software, and it needs to be built and maintained like software regardless of what the rest of the site is.
Why picking wrong is expensive
Building an app when a website would do means paying for complexity you will maintain forever. Building a website when you needed an app is worse — you will discover it after launch, and the fix is usually a rebuild rather than an addition, because the data model that should have existed from the start does not.
How to decide before you spend
Write down every piece of information the system must remember, and who is allowed to see it. If that list is empty, you need a website. If it is not, you need software — and you should say so in the brief, so the quotes you get are comparable.
We build both, and we will tell you which one your brief actually describes before quoting it.