Website or web app: which does your business need?

The question usually arrives after a demo. Somebody has seen a competitor’s booking system, or a supplier has shown them a client portal, and the site they have suddenly looks thin beside it. So which is it: a website, or a web app?

The distinction is real. The two are built differently, they fail differently, and they ask different things of you once they are live. But it is not the distinction most people assume, and it has nothing to do with how modern either one looks.

What is the difference between a website and a web app?

A website publishes information: the same pages, in the same state, for everyone who visits. A web app does work on a visitor’s behalf and remembers the result, so what each person sees depends on who they are and what they did last time. Everything else follows from that.

What a website is for

Persuading somebody who does not know you yet. Its job is to move a stranger from having found you to having contacted you without stalling on the way: what you do, who you do it for, evidence that you have done it before, and an obvious way to get in touch.

That is editorial work more than software work. The hard parts are the writing, the photographs and the order things are said in. The technical requirement is mostly that it loads quickly and reads well on a phone.

The upside is that a site in this shape is cheap to keep alive. Nothing is running, nothing can be half-broken for one visitor and fine for everybody else, and a page can sit unchanged for a year while still doing its job.

What a web app is for

Doing the work instead of describing it. A booking system that holds a slot and writes it into your calendar. A portal where each client sees their own documents. A dashboard, a quoting tool that does the arithmetic, a subscription product other people sign up and pay for.

The common thread is memory. Something has to be remembered between one visit and the next, per person, and it has to still be right when two people do the same thing at the same moment.

That is where the cost sits, and it is not the screens. It is the rules underneath them. What happens when a booking is cancelled after payment. What happens when two customers take the last slot in the same second. What happens when somebody changes their email address and then asks for an invoice from last year.

The line is memory, not sophistication

Three things reliably muddle this.

A contact form does not make it an app. It takes what somebody typed and sends an email. Nothing is stored, nobody logs in, and no state survives the visit. That is a website with a form, and it is the right answer far more often than people expect.

Looking modern is not being an app. Animation, a dark interface, a slick layout: all of that is presentation, and all of it is available on a set of static pages. Judging the category by the styling is how businesses end up paying for a database they never use.

An app is not the grown-up version of a site. They are not stages of the same thing. Large firms run marketing sites with no logged-in anything, and very small ones sometimes need a real application from the first week.

Four questions that settle it

Answer these about the specific thing you are picturing, not about your business in general.

Does anybody need to log in? If two different people must see two different things, you are describing an app. If everybody sees the same page, you are describing a site.

Does anything need to be remembered between visits? A booking, a balance, an uploaded file, a form somebody filled in half of. If nothing needs remembering, nothing needs a database, and most of the expense disappears with it.

Does the work finish inside it, or does it end in a conversation? A page that ends in an enquiry hands the job to a person, who can catch anything odd. A tool that takes a deposit has to be right on its own.

Would anyone notice at seven on a Saturday evening if it stopped working? This is the honest question. A site being down overnight is a bad day. A booking system being down on a Saturday is a lost weekend and a queue of phone calls on Monday, and that difference is a commitment, not a feature.

If the first two answers are no, you need a website. Build a good one and stop there.

What most businesses actually need

Not one or the other. A website, with one app-shaped piece inside it.

The pages do the persuading. Behind one button sits the single thing that genuinely has to remember something: the booking, the login, the calculator, the upload. Everything else stays static.

This matters because the app-shaped piece is the expensive half in every sense, to build and then to keep. Holding it to one clearly defined job is what keeps the project affordable and the result ownable. It also leaves you the option of using somebody else’s tool for that piece now and replacing it only if it stops fitting.

The failure mode is the opposite instinct: rebuilding the whole site as an application because one part of it had to be one.

What a web app asks of you that a website does not

Somebody has to own it. A page that is out of date is embarrassing. A booking system that double-books is a phone call from an annoyed customer. Someone in the business has to be the person who notices, and if nobody is, that is worth knowing before anything is built.

Accounts generate support. Password resets, the wrong email address, a customer who wants a refund and cannot find the button. That workload arrives with the logins and does not leave.

It moves underneath you. The payment provider changes something, the calendar provider changes permissions, browsers change behaviour. A static site absorbs most of that without noticing. An application has to be carried through it.

It is never quite finished. Every change in how you actually work has to be reflected in the rules, or people start working around the tool, which is the state the tool was bought to end.

None of that is an argument against building one. It is the part that decides whether you should build one yet.

Which one to ask for

The portal that prompted the question is often doing less than it appears to. Look at what it actually remembers, and how many screens carry that weight, before concluding you need the same thing.

If it turns out you need a website with a form that works and pages that answer the questions people ask before they get in touch, that is what we will tell you. It is a smaller job than the one you came in asking about, and it is quite often the one that pays.