Website or Web Application?
Last updated:
Where the line actually is
It is not about visual complexity or the number of pages. A site with 400 pages can be simple; a single-screen tool with a login can be genuinely hard.
The line is state. A website shows content that changes when someone publishes it. An application holds data that users change, which must remain correct under concurrent use, be protected by permissions, and survive being wrong.
The five questions
- Do users log in? Accounts bring authentication, password reset, sessions, and every security concern that follows.
- Does the system hold data users change? Then it needs validation, integrity and a real database design.
- Do different users see different things? Permissions multiply the testing surface.
- Is money involved? Payments bring compliance, reconciliation and failure paths that must be handled.
- Does it integrate with other systems? Every integration is an unknown with its own failure modes.
One yes probably makes it an application. Three yeses definitely does.
Why the cost difference is real
| Website | Web application | |
|---|---|---|
| Testing | Visual and link checking | Automated tests across states and roles |
| Security | Keep the platform updated | Auth, permissions, injection, session handling |
| Data | Content, versioned | Live data with integrity rules |
| Failure | A page looks wrong | Data becomes wrong — expensively |
| Ongoing | Updates and content | Monitoring, backups, support |
A broken website embarrasses you. A broken application makes your data wrong, and by the time anyone notices, the wrong data has been used for something.
The middle ground nobody names
Plenty of projects sit between: a site with a booking form that writes to a calendar, a brochure site with a client area holding a few documents.
Our rule is to treat the interactive part as an application and the rest as a site, with different standards for each. A form that writes into your CRM gets real error handling and a test suite; the About page does not need either.
Where people get caught out
The commonest expensive surprise: a brochure site is quoted and built, and then “a small client login area” is added in month three. That is not a small addition — it changes the hosting, the security posture, the testing and the maintenance obligation.
- “Just a login” — adds password reset, sessions, lockout, recovery, GDPR obligations
- “Just a dashboard” — needs data, permissions and something to keep it current
- “Just a form that saves” — needs validation, storage, retention and export
- “Just take payments” — needs reconciliation, refunds and a failure path
None of these are unreasonable requests. They are simply application features, and pretending otherwise at quoting time is how projects go wrong in month four.
What to do if you need both
Build them separately and link them. A fast static marketing site and a separate application on a subdomain is a common, sensible architecture: the marketing site stays quick and easy to change, the application gets the engineering it needs, and neither constrains the other.
It also means a marketing redesign does not require regression-testing your customer portal, which is a saving that repeats every couple of years.
Frequently asked questions
Can WordPress run a web application?
How do we budget if we are not sure which we need?
Can the same team build both?
Does an application need different hosting?
Planning a website or a web application?
Tell us what it needs to do and who for. We will tell you which of the four kinds of project it actually is, and what that costs.
Related services
What we build for problems like this one