When a website becomes a product

A lot of projects are scoped as websites and delivered as software. The brief describes pages; halfway through, someone asks whether customers can log in and see their orders. That question is the line, and it is worth recognising before rather than after.

Where the line actually is

It is not about page count, budget or how impressive the design is. A website becomes a product when it acquires any of these:

• Accounts — someone logs in, and what they see depends on who they are
• State — the thing remembers something between visits
• Permissions — different people are allowed different things
• Business logic — rules that produce different outcomes from different inputs
• Integration — it reads or writes data in another system

Any one of these changes the project. All five and you are building software, whatever the proposal called it.

Why it matters commercially

Websites and products fail in different ways, and they are maintained differently. A marketing site can be rebuilt every three years with little consequence. A product accumulates customer data, integrations and habits — replacing it is a migration, not a redesign.

You can rebuild a website. You have to migrate a product.

That difference should change the decisions made in week one: how the data is modelled, whether permissions are designed or bolted on, whether there is a test suite, and whether anyone has thought about who supports it at 9am on a Monday.

The parts that get missed

When a website drifts into being a product without anyone deciding it has, the same things go missing:

• Admin tooling, so support does not require a developer
• A data model that reflects how the business actually works
• Error handling for the paths that were not the happy one
• Monitoring, so you learn about problems before customers report them
• A deployment process that is routine rather than an event
• Documentation someone else could pick up

None of these are visible in a design review. All of them determine what the second year costs.

Deciding on purpose

The useful move is to ask the question early and answer it deliberately. Sometimes the right call is to stay a website — resist the login, keep the complexity out, and let another system own the state. That is a legitimate and often underrated decision.

Sometimes the honest answer is that the business needs a product, and the project should be scoped, staffed and budgeted as one. Either is fine. What causes trouble is arriving at the second while still paying for the first.

A test you can apply in a meeting

Ask what happens when two people use it at the same time and want different things. If the answer is 'nothing, they both see the same pages', it is a website. If the answer involves accounts, roles or records, you are commissioning software — and the estimate, the timeline and the team should all reflect that.