Why your website is a product, and what that changes

Ask a company when they last improved their website and you'll usually get a year. That answer is the whole problem in one sentence.

Sites that get answered with a year are projects: commissioned, built, launched, left alone, and eventually declared "dated" — at which point the cycle repeats and the accumulated learning is thrown away with the CSS. Sites that get answered with "last Tuesday" are products. They compound.

The difference is not budget, agency, or framework. It's the operating model.

The three-year cycle and what it costs

The pattern is familiar. Year one: the new site launches and performs well. Year two: it drifts as the business changes and the site doesn't. Year three: performance is visibly poor, blame lands on the design, and someone proposes a redesign.

The redesign is scoped as a fresh start. Everything gets rebuilt, including the parts that were working — because nobody recorded which parts those were. The new site launches, sometimes performing worse than the old one, and nobody can explain why because there is no baseline and no test.

A redesign is what you do when you've stopped measuring. It's not a strategy, it's a reset.

The real cost isn't the rebuild fee. It's the three years of compounding you didn't do, plus the institutional knowledge that walks out the door with the old codebase.

What "product" actually means here

Not that your site needs to be an app. Four operational things change:

1. It has owners, not vendors

Someone is accountable for the site's numbers every week — not for shipping a project, for the performance of a living asset. Without a named owner, a site defaults to whoever complains loudest, which is how you end up with a homepage designed by committee and a roadmap driven by internal opinion.

2. It changes continuously, in small increments

Weekly, not triennially. Small changes are safer, faster to attribute, and reversible. Ten small improvements over a quarter reliably beat one large redesign, and you know which of the ten worked.

3. Changes are hypotheses, not preferences

"Move the CTA up" is a preference. "We believe the CTA below the fold costs us qualified starts, because 60% of sessions never scroll past it — we expect a 10% lift in form starts" is a hypothesis. One can be evaluated. The other becomes an argument about taste, settled by seniority.

4. It's instrumented before it's changed

If you can't read the effect, you can't defend the work — and undefendable work is the first thing cut. Measurement isn't reporting overhead; it's what turns a cost centre into an investment case.

The stack that makes it possible

Operating models need infrastructure. A site that must be improved weekly cannot depend on an engineer for every change, or the queue becomes the constraint and the model dies quietly.

Three things carry most of the weight:

• Composable content. Pages assembled from a library of tested components, editable by marketing without a deploy. New landing page in an afternoon, not a sprint — the setup we cover in shipping a site your team can edit.
• Performance budgets in CI. Weekly changes accumulate weight. Enforce limits automatically or you will rebuild the site again in two years for speed reasons alone.
• Analytics wired to decisions. Not a dashboard nobody opens — a small set of numbers tied to specific hypotheses, reviewed on a fixed rhythm.

This is the architecture we build in web engineering engagements, and it's deliberately boring. The interesting part is what it enables: the ability to act on what you learn in the same week you learn it.

The weekly rhythm

The whole model runs on about ninety minutes a week:

1. Read the numbers (15 min). What moved? Anything ship last week worth reading yet?
2. Pick the constraint (15 min). One bottleneck — not five. Usually a step in the funnel that's leaking.
3. Write the hypothesis (10 min). Change, reasoning, expected effect, how you'll know.
4. Ship (the rest of the week). Small enough to land in days.
5. Record the outcome (10 min). Including the failures — especially the failures.

That last step is the one teams skip, and it is the one that compounds. A written record of what worked is the asset that makes year three cheaper instead of catastrophic. It's also what makes a redesign unnecessary: you never accumulate enough unexplained decay to justify one.

What changes in the numbers

The honest version: individual weekly changes are usually small. A 3% lift here, a 6% there, several that do nothing, occasionally one that does something significant.

Compounded across a year, small consistent gains outperform any single redesign we have ever seen — and you carry the learning forward instead of resetting it. Our platform work followed this pattern: the launch was the beginning of the performance story, not the end of it.

The second benefit is organisational. When the site improves visibly every month, it stops being the thing people complain about and becomes the thing people bring ideas to. That shift is worth as much as the conversion lift.

The short version

Redesigns are what happen to sites nobody measures. Give the site an owner, change it weekly in small hypotheses, instrument it before you touch it, and build the stack so marketing isn't blocked on engineering. Do that and the three-year cycle simply stops happening.

Related: the experimentation program that survives Q3 and motion that earns its place. Or see how we've built it for clients.