When a brochure site should be a web app

Teams often start with the right intention: keep the first version small and ship a clear website.

The problem comes later, when the site quietly starts doing application work.

Watch for behaviour, not page count

The turning point is rarely visual complexity. It is behavioural complexity.

If the site needs to do any of the following reliably, you are already moving into web app territory:

• user-specific state
• gated workflows
• saved progress
• dashboards or reporting
• operational tools for staff or partners
• multi-step forms that affect downstream systems

At that point the architecture should reflect the job.

Why the distinction matters

Brochure sites are usually optimised for reach, clarity, and speed. Web apps are optimised for correctness, state, and repeated interaction.

You can force one to behave like the other, but you normally pay for it later in the form of:

• brittle code paths
• poor analytics because key actions are hard to track
• SEO regressions from over-rendered client logic
• awkward content editing because everything is wired like product UI

A better split

We usually treat the public marketing layer and the product layer as separate concerns, even when they sit in the same codebase.

That gives the public site room to stay fast and indexable while the application surfaces can evolve around authenticated state and business logic.

Questions worth asking early

Ask these before the build grows around the wrong assumptions:

1. Is this page trying to persuade, or is it trying to operate?
2. Does the user need persistent state?
3. Will staff need tooling behind this later?
4. Does the content model need editorial control, or product logic, or both?

If the answers lean toward behaviour and state, build it like a product surface from the start. It is cheaper than retrofitting the separation once the site is already live.