Neil BusqueDesign & code Let’s talk

22 Compare

Web application vs website

I build both for a living. The distinction is simpler than the industry makes it, and picking wrong costs real money in both directions.

A website publishes. A web application does. A website shows the same pages to everyone who visits, and its job is to inform or persuade. A web application knows who you are, stores what you do, and changes state when you act: it has logins, data, and consequences. Most real projects need one of each, in that order.

The difference in one table

DimensionWebsiteWeb application
JobInform, persuade, rankRun a workflow, store and change data
VisitorsAnonymous, all see the same thingLogged in, each sees their own data
StateNone. Reading it changes nothingEverything. Actions create, edit, and delete records
ExamplesA marketing site, a blog, a restaurant's menu pageGmail, a CRM, a client portal, online banking
Search visibilityIts main channelMostly invisible, lives behind a login
Typical costLower, mostly design and contentHigher, plus permanent maintenance
When it breaksEmbarrassingOperational. Work stops until it is fixed

What makes something a web application

Three tests, and they are enough for almost every case:

  • Accounts. If different people see different things after logging in, it is an application. Identity is the line where a site starts needing security, sessions, and password resets.
  • Stored actions. If a user can create or change something that is still there tomorrow (a record, an order, a message), the thing has a database and is an application.
  • Consequences. If clicking a button moves money, books a slot, assigns a task, or sends an email on your behalf, the software is doing work, not just displaying it.

A page that fails all three is a website, no matter how animated it is. A spreadsheet with logins that passes all three is an application, no matter how plain it looks.

The gray zone, where most real things live

The clean split above dissolves fast in practice. An ecommerce store is a website until the cart, and an application from there on. A marketing site with a newsletter form is 99% website with a single application feature. A client portal is an application wearing a website's clothes.

Concretely, from my own work: this site is a website. It is built with Astro, its pages are public, and its job is to explain and rank. Orbit, the CRM I built, is a web application. It has multi-tenant accounts, pipelines, billing, and AI agents acting on records. The two share a browser and nothing else. The same pattern repeats across every example I have shipped: a public half that publishes and a private half that works.

Which one you actually need

The honest answer for most businesses is: a website first, and a web application only when a specific workflow demands one.

  • You need a website if the problem is "people cannot find us" or "our online presence embarrasses us". Building an app will not fix either, and an app you did not need is the most expensive kind. That work lives on my websites page.
  • You need a web application if the problem is operational: your team re-types data between tools, clients email you for updates a portal could show them, or the business runs on a spreadsheet that has outgrown itself. That is custom web app development.
  • You need both if you are launching a product. The application is the product, and the website is how anyone finds out it exists.

The cost difference, briefly

A website is a bounded project. A web application is an ongoing responsibility, because software with users and data has to be maintained for as long as it runs. That difference matters more than the initial quote, and it is why the two are priced so differently. I broke down the real numbers for both routes in what a web app costs in 2026.

If you are not sure which side of the line your project falls on, describe the problem to me and I will tell you straight, including when the answer is "you just need a website" or "you should buy something off the shelf".