People use the words interchangeably, and vendors are happy to let them, because the two things cost very different amounts to build. The distinction is simple once you see it: a website presents information; a web application performs work.
Your brochure site is a website. The portal where a customer logs in, checks an order, uploads a document, and submits a change request is a web application. They may look similar. Underneath they have almost nothing in common.
What actually separates them
- Purpose. A website publishes information. An application completes a task.
- State. A website looks the same to everyone. An application looks different for every user, because it remembers them.
- Accounts. Websites usually have none. For an application, accounts and permissions are the design.
- Data. A website holds content in a CMS that changes when marketing updates it. An application holds records that change all day.
- Failure impact. A website going down is embarrassing. An application going down means work stops.
- Ongoing cost. A website's is low and predictable. An application's is real and permanent.
The last two matter most. Because an outage stops work rather than marketing, applications need monitoring, backups, and someone accountable at 2am — and brochure sites mostly do not.
The middle ground people forget
Plenty of things sit between. A site with a contact form and a booking calendar is a website with two application-shaped features. That is usually fine, and usually much cheaper than commissioning "an app."
The honest test: does anything here need to remember who I am and what I did last time? If yes, you are in application territory and should budget accordingly. If no, you probably need a good website and should not let anyone talk you into more.
What web applications are usually for
- Customer portals. Order status, documents, invoices, support requests — the things that otherwise arrive as phone calls.
- Internal tools. The scheduling, tracking, and approval processes currently held together by a shared spreadsheet.
- Dashboards. Operational numbers pulled from several systems into one view somebody actually checks.
- Intake and workflow. Applications, permits, claims, or requests that need to move through defined stages with an audit trail.
Why the distinction changes the money
A marketing site is a project with an end. A web application is a system with a lifespan, and that means:
- Hosting is not $10/month. You are running a database, a backup regime, and probably a staging environment.
- Security is continuous. Accounts mean credentials, sessions, and password resets — all of which are attack surface. Dependencies need patching on a schedule, not when someone remembers.
- It is never finished. Real usage generates change requests forever. Budget maintenance from day one or watch it decay.
- Downtime has a cost. Which means monitoring and a support arrangement, the same way your other managed IT systems do.
Deciding what you need
Write down the three most important things a visitor should be able to do. If all three are "read something," "find something," or "contact us," you need a website. If any of them is "submit," "track," "approve," or "download my…", you need an application — and the sooner that is acknowledged, the more accurate every subsequent estimate becomes.
If it turns out you need both — most businesses do — they do not have to be one codebase, and they usually should not be. A fast marketing site and a separate secure application is a cleaner, cheaper architecture than one system trying to be both.
We scope both sides of that line as part of application development, and once something is live it needs the same backup and recovery discipline as the rest of your infrastructure.