The question comes up in almost every early conversation with a founder: "We need a website. Or maybe a web app? I'm not totally sure — what's the difference?"

It's a reasonable question. The terminology gets used loosely, and the distinction matters because it changes what you're building, what it costs, and how long it takes.

The practical distinction

A website is mostly informational. It presents content to visitors. Your homepage, service pages, blog, and contact form are all website territory. Visitors read, scroll, and occasionally fill out a form. The site doesn't change much based on who's looking at it.

A web application does things. It responds to user input, stores and retrieves data, enforces business logic, and often behaves differently depending on who's logged in. A client portal, a booking system, an invoicing tool, a marketplace — these are web applications. The line isn't always sharp, but the core distinction is between presenting information and processing it.

Some projects are clearly one or the other. A brochure site for a law firm is a website. A SaaS platform with user accounts and data is a web application. Many real-world projects fall somewhere in between — a restaurant website with an online reservation system has website elements and application elements.

Why the distinction matters for your budget

Websites and web applications have different cost profiles, and the difference is significant.

A well-built informational website might run from $3,000 to $15,000 depending on complexity. A web application with user authentication, data persistence, business logic, and an admin interface is a different category — the starting point is higher and the ceiling is much further up.

The reason is complexity. A website is mostly layout and content. A web application requires a database, server-side logic, session management, security considerations, and usually an API surface. Each of those layers adds engineering time.

This isn't to say web applications are always more expensive in absolute terms — a simple booking system might be more affordable than a complex marketing site. But if you're describing what sounds like an application and expecting website pricing, that gap will surface at some point in the conversation, and it's better to surface it early.

Signs you need a web application

You probably need a web application if any of the following are true:

Users need accounts. If people need to log in, have a profile, and see information specific to them, you need an application. User authentication is one of the clearest signals.

Data needs to be stored and retrieved. If the system needs to remember things — appointments, orders, messages, preferences — that requires a database and the application layer to interact with it.

Business logic needs to be enforced. "A client can only book one appointment per day" or "discounts apply after the fifth order" or "this form should only be visible to premium users" — these are rules that have to be implemented in code, not just displayed in content.

Multiple parties interact with the same data. If a client submits something and you need to review and respond to it, or if multiple team members manage the same records, you have a multi-party workflow. That's application territory.

The experience changes based on state. If what someone sees depends on what they've done before — their history, their role, their tier — you're building an application.

Signs you just need a website

If your main goal is to be found online, communicate what you do, and give people a way to contact you — that's a website. You don't need to overcomplicate it.

A lot of early-stage businesses get talked into building more than they need. If you're validating whether a market exists for your service, a well-built website is often the right first step. You can add application functionality later when you know what you're actually trying to build. It also helps to be clear on the difference between a website and a web app before you start any conversation with a developer.

The honest answer to "what do I need?"

The right answer depends on what problem you're solving. If you can walk me through what you want someone to be able to do — not just what they'd read — I can usually tell you within a few minutes whether you're describing a website, an application, or something in between.

That conversation is free and doesn't commit either of us to anything. Get in touch and we can figure out what you actually need before you spend a dollar on building it.