A lot of wasted budget comes from one unresolved question: do you need a website or a web application? The words get used interchangeably in sales conversations, and the difference is not cosmetic — it changes the cost, the timeline, and who maintains it afterwards.
Here is the distinction we use, and a test you can run in ten minutes.
The difference in one line
A website presents information. A web application changes information.
If your visitor reads, watches, and then contacts you, that is a website. If your visitor logs in, enters something, and expects it to still be there tomorrow — and expects someone else to see it — that is an application.
The ten-minute test
Write down the three most important things a visitor should be able to do on your site. Then, for each one, answer:
- Does it store something that must persist? A contact form emailing you does not count. A booking that must not be double-sold does.
- Does more than one person need different views of the same data? A customer sees their order; your staff sees all orders. That is an application.
- Are there rules? Discounts, approvals, stock limits, role permissions. Rules mean logic, and logic means application.
- Does it change without a developer? If your team needs to update it daily, you need a system with an admin area, not a page someone edits in code.
Zero or one yes: you need a website. Two or more: you need an application, and pretending otherwise will cost you more, not less.
What a good website actually needs
Businesses under-invest in the wrong parts of a website. The things that matter:
Speed on mobile over a poor connection. Most of your visitors are on a phone, on data, possibly on 3G. A site that takes eight seconds to show anything has already lost half of them. This is a technical outcome, not a design preference — ask any vendor what your target load time is and how they will measure it.
One clear next step per page. Not four buttons of equal weight. One primary action, repeated.
Findability. Real page titles, real descriptions, a sitemap, structured data, and content that answers questions people actually type. A beautiful site nobody finds is a brochure with extra steps.
Content you can update. If publishing a new page requires emailing your developer, you will stop publishing. That alone kills more sites than bad design.
What a good web application actually needs
Applications carry obligations a website does not:
Accounts and roles. Who can see what, who can edit, who can delete, and what happens when someone leaves the company.
An audit trail. When a number is wrong, you need to know who changed it and when. Retrofitting this later is painful.
Failure behaviour. What the app does when the network drops mid-save. The answer should never be "loses the work".
Backups you have actually restored. An untested backup is a rumour.
A support path. Someone has to answer when a user is locked out at month-end.
If a quote for an "app" does not mention these, it is a quote for a website with a login screen.
The hybrid case, which is most cases
In practice most businesses need both, and the mistake is building them as one thing. The pattern that works:
- A fast, public, content-driven site that is optimised for being found and for converting a visitor into an enquiry.
- A separate, authenticated system where the work actually happens — orders, leads, records, reporting.
Keeping them separate means the public site stays fast and simple, and the internal system can be as complex as the work requires without slowing anyone's first visit. It also means you can rebuild the marketing site in a week without touching the thing your operations depend on.
A sequencing recommendation
If you need both and cannot fund both at once, build the public site first — but only after you have mapped the internal system. The map costs you a couple of days and stops you from designing a website that promises things the future system cannot deliver.
Then build the internal system for the single process that hurts most. Not all of them. One.
How to brief either one
For a website, bring: who your customer is, what they need to believe before they contact you, and the three pages you know you need.
For an application, bring: the process as it works today (including the messy parts), the spreadsheet or notebook it currently lives in, and the list of people who touch it.
That is enough for anyone competent to give you a real answer. If you want us to run the test with you and say plainly which one you need, book a consultation.