Website or web app: what are you actually building?

The distinction matters because the build is different

Founders use "website" and "web app" interchangeably when they describe what they want, and we ask the same clarifying question every time: which one is doing the work?

The answer matters because the two are not the same product. A website is an explanatory surface. Its job is to take a stranger from "what is this" to "I want to talk to someone or sign up." It is read more than it is used. A web app is a product surface. Its job is to take a logged-in user from intent to outcome — a transaction, a created artifact, a workflow completed. It is used more than it is read.

Conflating the two leads to predictable failures. Marketing sites built like apps feel cold and load slowly. Apps built like marketing sites feel impressive in demos and useless in daily work. The build, the team, the framework, the metrics, even the maintenance rhythm differ.

What a website actually does

A website does five things and almost nothing else. It explains who the company is and what it does. It surfaces enough proof — work, testimonials, case studies, logos — that a sceptical visitor can take the company seriously. It answers the questions a buyer is going to ask before talking to anyone. It captures intent — a contact form, a calendar booking, a newsletter signup, a demo request. And it stays out of the way of search engines so the right traffic can find it.

That is the whole job. Everything else on a marketing site — animations, scroll-jacking, gated content, popup modals, multi-step quizzes — is either decoration or friction, and almost always friction.

Marketing sites are mostly read on mobile. They are mostly visited by people who are not yet customers. They are judged in seconds, not minutes. The content is the product. Polish helps, but clarity wins.

What a web app actually does

A web app does one thing well and the rest of its work supports that one thing. It lets a logged-in user complete a workflow they care about — managing finances, scheduling work, tracking inventory, collaborating on a document, analysing data.

The job of every screen is operational. Empty states need to be useful, not just empty. Loading states need to be honest, not just animated. Error messages need to recover the user, not just notify them. The interface needs to hold up to a user opening it forty times in a week and seeing the same screens repeatedly. The aesthetic of "shiny new tool" wears off in a fortnight. The aesthetic of "still useful in month nine" is the one that matters.

Web apps are mostly used on desktop, by people who already understand the company. They are judged in months, not seconds. The workflow is the product. Polish helps, but reliability wins.

When founders confuse the two

The most common version of this confusion looks like a marketing site with too much app inside it. A homepage with a live data dashboard. A pricing page with an interactive calculator that lags. A signup flow that asks for too much before showing the product. The visitor came to read and gets handed work to do instead.

The opposite version is a web app with too much marketing inside it. An onboarding flow that reads like a sales pitch. A dashboard that explains its value before letting the user see it. A settings page with promotional banners. The user came to do work and is being sold to during it.

Both versions fail because the underlying job — explain or operate — is being confused with the other one. The fix is rarely about adding or removing features. It is about answering the question of which surface the user is on, and committing to it.

The platform implications

The framework choice usually follows from this distinction. Marketing sites belong on platforms optimised for content velocity, SEO, and design polish — Webflow, Framer, Next.js with a CMS, depending on the team. The cost of a wrong framework choice here is high: a marketing site that is hard to update calcifies within months.

Web apps belong on frameworks optimised for application state, data, and user accounts — Next.js, Remix, Rails, depending on the stack. The cost of a wrong framework choice here is also high, but in a different way: an app built on the wrong stack becomes hard to extend exactly when the product needs to grow.

The temptation to put both on the same codebase, served by the same team, with the same conventions, is real. Sometimes it works. More often it produces a stack that is good at neither — a marketing site that is slow because it inherits app dependencies, and an app that is hard to evolve because it shares routes and components with the marketing site.

A practical test

Before any project starts, we ask a simple question: when someone uses this thing, will they be reading or doing?

If reading, it is a website. The success metric is conversion — visits to enquiries, enquiries to qualified conversations.

If doing, it is a web app. The success metric is activation and retention — signups to first useful action, first useful action to second session.

Some products need both, and that is fine. The clarity is in naming which is which. Marketing site at the front door, web app behind the login. Different teams, different builds, different release rhythms. Connected at the boundary, not blended through.

What gets cut from each side

Marketing sites get cut down most when teams stop trying to be everything. The blog with eighty thin posts. The careers page with no jobs. The case studies page with three half-finished entries. Each one is a small failure of credibility. Better to ship four polished pages than fourteen messy ones.

Web apps get cut down most when teams stop building for the user who has not arrived yet. The settings screen for preferences nobody has expressed. The admin panel for a team that has not been hired. The integration with a tool nobody on the customer side uses. Each one is build effort that delivers nothing today.

The shape of a strong digital presence usually ends up being two products, intentionally separated. One that explains. One that operates. Each one good at its job. Neither pretending to be the other.