Website vs. web app: what you're actually buying.
Clients say "I need a website" and mean three different things depending on the week. Sometimes they mean a page that explains what the business does. Sometimes they mean a system their customers log into and use. Those are not the same project, they don't cost the same, and confusing them is how quotes go sideways. Let's fix the vocabulary.
A website is a brochure that loads
A website exists to tell people something. Who you are, what you sell, why you're credible, how to reach you. It's accessible by URL, it can be static or backed by a small database, and its entire job is communication. Nobody expects to "do" anything on it beyond reading, filling a form, or clicking to call. A restaurant site, a law firm's about page, a portfolio, a landing page for a product launch — all websites, no matter how much motion or polish you bolt on.
Complexity on a website is cosmetic, not functional. You can add a blog, a booking widget, a chat bubble, and it's still fundamentally a website — information plus a few conveniences. The build is front-end heavy: layout, typography, content, maybe a CMS. There's no real "logic" happening. Nothing is being computed, stored per-user, or acted on.
A web app is software that happens to run in a browser
A web app exists to let someone do something — manage data, complete a workflow, interact with a system that remembers them. Think dashboards, scheduling tools, internal ops platforms, anything with accounts, permissions, or state that changes based on what the user does. The job isn't communication, it's function.
That changes the build completely. You need a backend: a database, business logic, authentication, APIs. The front end isn't laying out paragraphs, it's rendering state that has to stay correct — what happens when two people edit the same record, what happens when a request fails halfway through, what happens at scale. This is engineering, not design with extra steps. It's also why web apps take longer and cost more: you're not paying for pixels, you're paying for a system that has to keep working after you leave.
| Question | Website | Web app |
|---|---|---|
| What's the primary job? | Inform, persuade, present | Let users complete tasks |
| Does it need a backend? | Usually not, or minimal | Yes — database, auth, logic |
| Does content change per user? | No | Yes, constantly |
| Typical build time | 1–3 weeks | 4–16+ weeks |
| What breaks if it's rushed? | Looks unfinished | Loses or corrupts data |
If nobody logs in and nothing needs to be remembered between visits, you don't need an app. You need a good website, and you should be relieved about that — it's the cheaper, faster answer.
Where clients actually need which
A service business that wants leads: website. A SaaS company whose product is the interface: web app, obviously — there's no separating the two. Most of my work sits at the boundary, and that boundary is where the interesting decisions happen.
- You need a website if: your goal is visibility, credibility, or lead capture, and the "action" a visitor takes is a form submission, a phone call, or a booking handed off to a third-party tool.
- You need a web app if: users need accounts, their data has to persist and update, multiple people interact with shared state, or the product's value only exists once someone is logged in and using it.
Where the line blurs
Two features get misclassified constantly, and they're worth calling out by name.
Booking widgets. Embedding Calendly on a website doesn't make it a web app — you're borrowing someone else's backend. It only becomes app territory when you want the booking logic custom: your own availability rules, your own database of appointments, your own confirmation flow. That's a real feature build, not a widget.
Dashboards. A page showing "live stats" sounds like a website feature until you ask where the numbers come from. If they're pulled from a database that updates per user or per account, you've quietly built a web app, and it needs to be scoped, priced, and engineered like one — with real attention to what happens when the data is wrong, missing, or late.
The tell is always the same question: is this page the same for everyone, or does it depend on who's looking at it and what they've done? Static content is a website problem. Stateful, personal, changing content is a web app problem, and it needs backend thinking from day one, not bolted on after the front end is "done."
Cost and effort follow function, not looks
A gorgeous website with heavy animation can look more "advanced" than a plain but functional internal tool, and clients sometimes price them backwards because of it. Don't. Visual polish is a front-end cost. Data integrity, authentication, and business logic are engineering costs, and they scale with what the software actually has to guarantee — not with how impressive the demo looks on a call. Ask what has to be true a year from now, with real users, real data, and real edge cases, and you'll know which one you're actually buying.
— Allie
Not sure which one your project is?
Reserve a Consultation