Development

Web application or website: where the line is

A website shows information; an application does the user's work. Where exactly the line runs and why a user account changes the class of the task.

Formally, both a website and a web application open in a browser at an address, and from the client's side the difference often looks like a difference in complexity: "a website is simpler, an application is harder". In reality they're different classes of task with different architecture, a different team and a different cost of ownership. It pays to understand the line before a user account area appears in the specification.

The difference is in the verb

A simple distinction: a website shows, an application does.

A website conveys information from the company to the visitor. The content is prepared in advance, is the same for everyone who opens it, and changes when an editor changes it. The visitor reads, compares and finally leaves an enquiry. The enquiry is the edge of the website: from there, work continues in email, the CRM, on the phone.

An application does the user's own work. People come to it not to read but to get something done: place an order and track it, build a report, assign a task, sign a document, check their figures for the month. The result of their actions is saved and affects what they see next time. Everyone's content is their own.

The practical consequence: on a website the visitor is anonymous and interchangeable; in an application they're a specific person with a history. That's the line.

Three things that come with an application

As soon as the project involves user work, three entities appear that the website didn't have at all.

State. An order has a status, a document has a version, a task has an assignee and a deadline. States change and move from one to another according to rules, and those rules need to be described. "Can only be cancelled before payment", "can't be edited after approval" — phrases like these in a discussion mean you're designing an application.

Roles. An application rarely has one type of user. There's a client and a manager, an employee and a supervisor, an admin. Each sees their own things and can't do everything. Access rights aren't checkboxes in settings but logic that runs through the whole product: every screen and every data request has to ask who exactly is making it.

Data that can't be lost. Text on a website can be restored from a backup and rewritten. Users' orders, transaction history and uploaded documents can't be recreated. This changes the requirements for backups, database migrations and how updates are rolled out.

A fourth almost always joins these three: mistakes become expensive. A typo on a services page is an annoyance. An error in calculating warehouse stock is money and an investigation. Hence testing that could be trimmed on an ordinary website but can't be here.

"Let's add an account area to the website"

This phrase sounds like a small extension but means a change in the class of task. Let's look at what stands behind it.

Registration and login appear — so you need passwords, password recovery, email confirmation, brute-force protection, sessions and their expiry. User data appears — so you need to decide where it's stored, who sees it, how it's deleted on request. User-dependent content appears — so the usual caching of whole pages no longer works, and performance is calculated differently.

Then comes the question that decides everything: where the account area gets its data. If users should see their orders, those orders already exist somewhere — in the accounting system, the CRM, the warehouse software. The account area becomes a window onto someone else's database, and half the project turns into integration: how to fetch the data, how often to update it, what to show when the source is unavailable.

A user account area isn't a section of a website but a separate product that lives next to it and often outlives it.

So the decision to "bolt an account area onto the existing website" isn't always bad, but it should be taken as a decision to launch a second project, with its own budget and its own support. More about this class of task is in the web applications section.

In-between cases

The line isn't always obvious. A few typical situations and where they actually belong.

  • An online store. Formally it's an application: cart, orders, statuses, payment. But it has a large storefront part that everyone sees and that must be indexed by search engines. So a store is almost always a hybrid: public pages follow website rules, everything after the cart follows application rules.
  • A calculator on a website. Calculates in the browser, saves nothing, the result affects nothing — it's still a website. As soon as the calculation is saved to the user's personal history, it's an application.
  • A blog with comments. Users create something, but the core of the product is publishing content. It's a website with limited interactivity, not an application.
  • An admin dashboard for staff. No indexing needed, no public traffic, but roles, states and lots of tables. A pure application, even if there are few screens.

Look not at the number of buttons but at whether the result of a user's action is saved and affects further work.

What changes in the development process

The difference in class of task also changes how the project is run.

  1. Design of logic before visual design. For a website, work starts with page structure and prototypes. For an application — with scenarios, roles and the data model. Beautiful mock-ups drawn before the states are described will have to be redone.
  2. A different scope of work. In an application, a significant part of the effort isn't visible on screen: backend, database, access rights, integrations, error handling.
  3. Launch isn't the finish line. A website can go unchanged for months after handover. An application starts living after launch: users find inconveniences, new scenarios appear, you need a feedback channel and regular updates.
  4. Support is mandatory. An application has on-call duty: if it goes down, people can't work. It's a separate agreement, not a gesture of goodwill.
  5. The cost of ownership is higher. Server, backups, monitoring, dependency updates, incident analysis. It's a recurring expense and should be budgeted from the start.

How to tell you need an application

Check yourself against these questions. Two or three "yes" answers are enough to stop calling the task a website.

  1. Does the user need to log in as themselves to see their own things?
  2. Is the result of their actions saved, and does it affect what they'll see tomorrow?
  3. Are there several types of users with different rights?
  4. Do objects have statuses that change according to rules?
  5. Does data need to be exchanged with another system — accounting, payments, warehouse?
  6. Would an incorrect calculation or a lost record cost money?

If every answer is "no", you need a website, and turning it into an application means paying for complexity nobody will use. The opposite mistake is more common and more expensive: a project starts as a website, six months later an account area is added, then roles, then an integration — and you end up with an application built on a foundation that was never designed for it.

If your answers give a mixed picture, what's usually missing is a description of scenarios: who exactly does what in the system every day. Describe that — and let's discuss where the line runs in your case.