Two businesses ask for "a website with a customer area". One receives a quote for six thousand pounds and the other for sixty. Neither supplier is wrong — they have understood different projects.
The distinction
A website presents information. Pages, images, articles, a contact form. The visitor reads and occasionally submits something. The content changes when somebody edits it.
A web application lets people do work. Users log in, create records, change them, act on them. The system holds state, enforces rules and produces different results for different people.
A useful test: if you removed every user account, would the thing still make sense? A website would. An application would not.
Why the cost difference is so large
Not because applications have more screens. Because most of the work is in what happens when things go wrong.
Every action needs a failure path
A page that displays a service description has one behaviour. A form that creates an order has many: the stock ran out mid-order, the card was declined, the session expired, the user pressed submit twice, the address failed validation, the connection dropped halfway.
Each of those needs deciding, building and testing. That is where application budgets go.
Permissions
Who can see what, who can change what, who can approve what. A manager sees their team's records but not another department's. A customer sees their own orders and nobody else's.
Permissions must be enforced on the server for every request, not just hidden in the interface. Getting this wrong is how customer data leaks, and doing it properly touches everything.
Data integrity
Websites can tolerate a typo in a paragraph. Applications cannot tolerate an invoice with no customer, an order for negative quantity, or two people editing the same record and one silently overwriting the other.
It never really finishes
A brochure site can sit unchanged for two years. An application accumulates requests from the day it launches, because people use it daily and daily use generates opinions. Budget for continuing development or expect frustration.
The screens are perhaps a fifth of a web application. The rest is rules, permissions, edge cases and the tests that stop them recurring.
Which do you actually need?
You need a website if the job is to be found, explain what you do and generate enquiries. That is most businesses, and it is not a lesser ambition.
You need a web application if:
- Customers or staff need to log in and see data specific to them.
- The system must calculate something using your own rules.
- Records progress through a workflow with states and approvals.
- Data must stay in step with another system in both directions.
- Different people must see different things.
Common examples: a customer portal showing live job status, a quoting tool that applies your pricing rules, a booking system that respects real engineer availability, a compliance register with audit history.
The middle ground
Plenty of businesses need a website with one application-like feature — a booking flow, a quote calculator, a document download area for registered clients.
That is legitimate and it is where scope discipline matters most. The feature will cost more than the rest of the site combined, and it is worth saying so out loud at the quoting stage so nobody is surprised.
Build only after you have ruled out buying
Before commissioning an application, work through existing products properly. Not a glance at two websites — a genuine evaluation, including a trial with your own data.
Building is justified when your process is genuinely unusual, when existing products would force a way of working that costs you real money, or when the system is part of what you sell rather than support for it. We work through the decision in build versus buy.
The common and expensive mistake is building a slightly different version of something you could have subscribed to.
What to expect if you do build
Discovery first. Several weeks understanding the actual process, including the exceptions people handle informally. Those exceptions are the project.
A small first release. The narrowest thing that is genuinely useful, in real use, before the rest is specified. Requirements written in advance are guesses; requirements written after three months of use are informed.
Ongoing cost. Hosting, monitoring, security updates, support and continued development. A reasonable planning figure is a meaningful percentage of the build cost every year.
Somebody who owns it internally. Applications need a decision-maker on your side. Without one, changes queue and the system stops matching how you work.
Our web applications team builds systems for UK businesses, and starts by checking whether you need one. Discuss your requirements and we will tell you honestly which side of the line your project sits on.
