BUILD
When a website stops being a website and becomes an application
5 min read
A website becomes an application the moment it stores state on behalf of a specific user, because from that point it needs accounts, permissions, data migration and a support model that a brochure site never requires.
Plenty of projects are scoped as a website and delivered as an application. The brief says five pages and a contact form. Somewhere in the third meeting someone says customers should be able to log in and see their orders, and the project quietly changes category without the budget or the timeline noticing.
The line is worth being able to see, because almost everything on the other side of it costs more and lasts longer.
The line is state
A website presents the same content to everyone, or content that varies by page rather than by person. It can be rebuilt from its source at any time and nothing is lost.
An application holds state on behalf of a specific user. The moment that is true — an account, a saved basket, a submitted application, a document someone uploaded — you have data you cannot regenerate, and everything downstream changes.
What changes once you cross it
These are the costs that appear on the other side of the line and that brochure-site estimates do not include.
- Accounts, which means password resets, lockouts, support requests and a decision about identity providers
- Permissions, because at least two kinds of user will exist and one of them should not see what the other sees
- Data you cannot lose, which means backups that have been restored in a test, not just configured
- Migrations, because the shape of stored data will change and existing records have to come with it
- A support model, because an outage now stops people working rather than just being embarrassing
The questions that reveal it early
Three questions in the first meeting usually settle which kind of project this is. Does anyone log in? Does the site need to remember something between visits? Does it need to read from or write to another system?
Any yes means application. Two or three means the estimate should be built from the data model rather than from a page count, because the page count will be the smallest part of the work.
Being honest about which you need
Not every organisation that wants a portal needs one. A login that exists so customers can download two documents is often better served by sending the documents, and the application that replaces it carries years of maintenance for a convenience.
Equally, a business running its operations through a shared spreadsheet usually needs the application sooner than it thinks, and building another brochure site is deferring the real problem.
The useful test is whether the state being stored is doing work. If it is, build the application properly. If it is not, do not take on software you will have to maintain.
What this means for the brief
A website brief can reasonably describe pages, content and design. An application brief has to describe who the users are, what each is allowed to do, what data exists, where it comes from and where it goes.
That document is harder to write and it is the one that makes the estimate meaningful. Without it, the number in the proposal is a guess about a page count.
Questions we get asked
How much more does a web application cost than a website?
The build is usually a multiple rather than a margin, and the larger difference is ongoing. A brochure site needs hosting, updates and occasional content changes. An application needs those plus support for user problems, data migrations as the model evolves, dependency updates and security patching for as long as it runs.
Can WordPress handle an application?
It can handle accounts and structured content well, and it is a reasonable choice when the application is close to content with some gating around it. It gets strained when the data model is genuinely bespoke, permissions are complex, or the interface needs to behave like software rather than like pages.
Can we start with a website and add the application later?
Often yes, and it is frequently the right call. It works much better when the first build is made with the second in mind — a sensible content structure, a hosting arrangement that can grow, and no decisions that would have to be unpicked. Say the plan out loud at the start, because it changes a few early choices cheaply.