Do you need a website or a product? How to tell before you build

A site that informs and a product that does something are different builds

A lot of projects get scoped as a website and turn into something else halfway through. The brief starts with pages and navigation, and somewhere around the third round of feedback it becomes clear that people are expected to log in, save something, come back to it and be shown what changed. At that point the project is no longer a website, and continuing to treat it as one is what makes it run late.

The distinction that actually matters

The useful test is not how the thing looks or which tools built it. It is whether the visitor is meant to read or to do. A website presents information: who you are, what you sell, why it is worth someone's time, how to get in touch. It succeeds when a stranger understands the offer and takes one clear next step.

A product holds state. Somebody signs in, does work, and expects that work to be there tomorrow. The moment there are accounts, saved records, permissions or anything that changes based on who is looking at it, you are building software with a front end rather than a set of pages.

Why the difference changes the whole plan

On a website, most of the complexity is in the first screen of each page. Structure, message and hierarchy carry the work, and once a template is designed it mostly repeats. Content changes, behaviour does not.

On a product, the visible screens are the small part. Underneath sit the states nobody puts in a mockup: what an empty account looks like before there is any data in it, what happens when a request fails halfway, what a user with restricted access can and cannot see, what the interface does while it is waiting. Those states are where the time goes. A design that covers only the populated, everything-worked version of each screen is perhaps a third of the actual work, and the remaining two thirds tend to get discovered during the build.

Signals you are building a product and calling it a site

A few things reliably indicate the scope has moved. Two people need to see different content at the same URL. Something has to be saved and returned to later. There is an admin who manages what other people see. Data comes in from another system and has to stay in sync. Someone has asked what happens when two people edit the same thing.

Any one of these can be handled inside a marketing site with some care. Three or four together means the honest description of the project has changed, and the plan should change with it rather than absorbing the difference quietly.

Naming it early is the cheap version

Both kinds of project are worth doing and neither is superior. A well-made informational site is the right answer far more often than the industry admits, and it will usually outperform a half-finished platform at the job of explaining what a company does.

The expensive mistake is not choosing wrong. It is not choosing at all, then discovering in the build that the design covers the happy path and nothing else. It is worth being blunt about this at the start of a project, because the answer determines how the work is scoped, how long it takes, and what the design has to cover before any product design or web development begins.