The line between these two has blurred enough that people use the words interchangeably, which causes real problems when it's time to scope and budget. They're different kinds of work carrying different risks, and being wrong about which one you're commissioning is expensive.
Here's the distinction that actually holds up.
The question that separates them
Does a user log in and change something that persists for them?
A website presents. Everyone sees essentially the same thing, content changes when you publish, and a visitor reads, watches, and maybe submits a form.
An application maintains state on someone's behalf. People have accounts. What they see depends on who they are and what they've done. Their actions change stored data that has to still be correct tomorrow.
That's the whole line. Not complexity, not how it looks — whether the system is responsible for someone's data over time.
Why it matters more than it sounds
Because everything gets harder once the answer is yes.
A marketing page is either right or wrong, and you can see which by looking at it. An application has states: what happens when two people edit the same thing, when a payment half-succeeds, when a session expires mid-form, when a device syncs after being offline. Most of the work in an application lives in those situations, and none of it is visible in a design.
The second difference is permanence. If a website has a bug, a page looks wrong until it's fixed. If an application has a bug, it can corrupt data people depend on. That changes how it must be built, tested, and maintained — and it's why applications carry ongoing cost in a way brochure sites don't.
Examples from my own work
Victory Church is a website. It's substantial — a sermon library, service times, giving, a kids section — but everything it presents is published content, and a visitor doesn't have an account that changes what they see.
Ruach is an application. Churches connect their own content, it's processed and stored per organization, staff log in to manage it, and each church's library is separate from every other church's. There are accounts, permissions, and stored state that has to stay correct.
Handled is an application too, and a good illustration of where cost hides. It's a household app — chores, schedules, fairness — and the visible part is a handful of screens. The actual work is in scheduling logic, fairness calculations, notifications that don't nag, syncing across devices, and subscriptions. Almost none of that is on screen.
The middle ground, which is most projects
Plenty of sites are mostly website with a small application inside: a marketing site with a booking system, a members area, or a client portal.
That's a legitimate and common shape, but it should be scoped honestly. The application part carries application-level cost even if it's five percent of the pages, and the usual estimating mistake is pricing the whole thing at website rates because most of it is pages.
How to figure out which you need
Work through your must-haves and mark the ones that require an account, store per-user data, or have to stay correct over time rather than just be accurate today.
If nothing gets marked, you need a website. Build it well and spend the savings on content.
If a few things get marked, you need a website with a defined application component — and it's worth asking whether an existing tool could handle that part. Booking, payments, scheduling, and email are solved problems, and integrating a mature service is almost always cheaper than building your own.
If most things get marked, you're commissioning software. Budget for maintenance from the start, because launch is the beginning of the cost, not the end of it.
The thing worth being honest about
The most expensive projects I've seen went wrong here — not in design or development, but in scoping something as a website when it was software.
Nobody wants to hear that the thing they described is bigger than they hoped. But finding out at the start is much cheaper than finding out at eighty percent, and a good studio should tell you which one you've actually got before either of you commits.