Almost every quote you receive will use both phrases, often in the same paragraph, and the price difference between them can be a factor of five. That is not vendors being slippery. They describe genuinely different engineering problems, and the reason projects get rebuilt eighteen months after launch is usually that they were scoped as one and turned out to be the other.
Here is the test we actually use.
The dividing line is state, not size
A website presents. Everyone who visits a given URL sees the same thing, and nothing a visitor does needs to survive them closing the tab. A fifty-page site with video, animation and a complex information architecture is still a website.
An application holds state on the visitor's behalf. There are accounts, saved records, permissions, or a workflow that spans more than one session. A five-screen tool where two people can edit the same record is an application, and it is a harder engineering problem than the fifty-page site.
Ask one question: if two people use this at the same time, can they interfere with each other? If the answer is no, you are commissioning a website. If the answer is yes or if it is "I don't know" you are commissioning an application.
Why the architectures are genuinely different
This is not a pricing convention. The two shapes optimise for different things, and the optimisations are close to opposites.
A website optimises for delivery
- The best possible architecture is pre-rendered HTML on a CDN edge, because there is no per-visitor computation to do.
- Success is measured in Largest Contentful Paint, crawlability and conversion.
- It scales without effort: a static file serves ten visitors or ten million the same way.
- It can be genuinely cheap to run often within a free hosting tier.
An application optimises for correctness
- Nothing can be cached globally, because every response depends on who is asking.
- Success is measured in whether the rules hold under concurrent use.
- Scaling is a real engineering exercise, and the database is usually the first limit.
- Running cost tracks usage, and the operational burden monitoring, backups, incident response never goes away.
Every hard question in an application is about the second list. What happens when two people save the same record within a second of each other? What happens when a session expires halfway through a multi-step form? Who is allowed to see this specific row, and where is that enforced? None of those questions exist for a marketing site, and all of them have to be answered before you write the first screen.
The specific mistake that causes rebuilds
The expensive failure is almost always the same one: a website is built, then a login is added to it.
It starts reasonably. The site is live, and someone asks for a customer area just a page where clients can see their own documents. A page is added, an auth plugin goes in, and it works. Then the customer area needs roles. Then it needs an admin view. Then a second business unit needs its own data separated from the first.
By that point you have an application with no permission model, authorisation enforced by hiding buttons in the interface, and no audit trail built on infrastructure chosen because it served static pages quickly. The rewrite is not a failure of the developers who built the original. The original was correctly built for what it was asked to be.
If there is any realistic chance of accounts appearing within two years, say so at the start. Designing a data model that can accommodate them later is nearly free. Retrofitting one is not.
Where the boundary genuinely blurs
Three cases sit on the line and are worth naming, because they get argued about in every scoping call.
E-commerce. A storefront is mostly a website the catalogue is public, cacheable and identical for everyone. Checkout and accounts are an application. The reason established platforms are usually the right answer is that they have already solved the application half properly, including the compliance parts you do not want to own.
Contact forms. A form that sends an email is still a website. Nothing persists in a way anyone reads back. The moment submissions become records someone manages in an interface, it is an application.
Content management. A CMS is an application, but it is somebody else's application. Using a headless CMS to edit a static site keeps your project on the website side of the line entirely, which is the whole appeal.
What to do with this
- Write down every piece of information the system must remember, and who is allowed to see each one. If that list is empty, it is a website.
- Ask whether two people using it simultaneously can interfere. If yes, it is an application.
- Ask what happens two years out. Scope for that answer, not just for launch.
- If it is a website, insist on pre-rendered HTML and a real performance budget those are the things that determine whether it earns anything.
- If it is an application, insist that the permission model is designed before the screens are. It is the one decision that touches every query in the system.
The two are not a hierarchy. A superbly engineered marketing site is more valuable to most businesses than a mediocre application. The failure is only ever in building one while believing you are buying the other.