A website tells people about you. A web application lets people do something. That's the whole distinction, and almost every confusing quote traces back to someone assuming they need one when they actually need the other.

What counts as a website

Marketing pages, a blog, a portfolio, a landing page with a contact form. Content flows one direction, from you to the visitor. The visitor reads, maybe fills out a form, and leaves. There's no login, no account, no data that changes based on who's looking at it.

What counts as a web application

Anything where a user logs in and the page changes based on their account, their data, or their permissions. A dashboard, a booking system, an internal tool, a customer portal. The visitor isn't reading, they're working, creating records, updating state, triggering actions that persist.

Why the distinction changes the price

A website is mostly a design and content problem. A web application is a data and logic problem, and logic is what takes engineering time. Authentication, permissions, database design, edge cases around what happens when two users touch the same record at once, none of that exists on a marketing page.

A quick test

Ask yourself, does this need a login? If the answer is no, you almost certainly need a website, not a web application, and the project should be priced and scoped like one.

The middle ground

Plenty of projects are genuinely both. A company site with a client login area bolted on. A marketing page in front of a SaaS product. In that case, we usually recommend building the marketing side as a fast, simple site and the logged-in side as its own application, because forcing both into one architecture tends to make the simple part slower than it needs to be.

Not sure which one you need?

Tell us what the thing is supposed to do, not what you'd call it, and we'll tell you honestly which category it falls into and roughly what that means for cost and timeline.

Not sure which one fits your project?

Book Free Consultation