Your Website Isn't a Project. It's an Operation.

There's a moment we see over and over again. A business commissions a new website. The agency builds it, everyone's happy, there's a celebratory launch. Six months later the site is slower, the contact form has quietly stopped sending emails, the SSL certificate expired over a weekend and nobody noticed, and the owner is wondering why enquiries have dropped.

The problem isn't the agency. It isn't the technology either. The problem is the mental model: the website was treated as a project — something with a start, an end, and an invoice — when in reality it's an operation that either someone keeps alive, or it slowly degrades.

What actually happens after launch

No website stands still, even when nobody touches it. The environment around it moves constantly.

The libraries and CMS it's built on receive security updates. Skip a few and you become an easy target for automated attacks that scan the internet around the clock. Browsers and Google keep moving the bar — what counted as a "fast site" yesterday is a mediocre Core Web Vitals score today, and a lower position in search. Integrations break silently: the payment provider changes an API version, the email service tightens its rules, and the form that worked for a year and a half stops — no error on screen, no warning.

None of this is dramatic on its own. What's dramatic is the accumulation: after a year without care, the "new" site is technically old.

Why the "project" model fails

When the site is a project, the budget ends on launch day. Everything after that is "extra" — and because it's extra, it gets postponed. Responsibility ends too: the agency has delivered, the internal team has no capacity, and as a result the site belongs to no one.

The irony is that the most important period in a website's life is right after launch. That's when the real users arrive, the real traffic, and the real problems no test ever caught. That's when you see which pages actually convert and which are dead weight. The project model wraps up exactly when things get interesting.

What the operational model looks like

Nothing exotic is required. You need three things, done consistently:

Monitoring. Someone (or something) needs to know within minutes, not weeks, when the site goes down, slows down, or a form stops working. Monitoring is cheap; an undetected problem is not.

Scheduled maintenance. Security updates, backups that have actually been tested for restore, certificate and domain renewals. Boring work — which is exactly why it gets skipped, and exactly why it needs to be automated or contractually someone's responsibility.

Data-driven iteration. The site generates information every day: where people come from, where they drop off, what they search for. The operational model means once a month someone looks at that data and makes one or two small, measurable changes. Ten such improvements over a year are often worth more than one "redesign" costing tens of thousands.

The practical question: who does it?

There are three approaches that work, and one that doesn't.

The ones that work: an internal person with clearly allocated time (not "when there's time left over"), an external partner with a maintenance contract and defined responsibilities, or a combination — an internal owner of the outcome, an external executor of the technical side.

The one that doesn't: "we'll call someone if something breaks." That's not a plan, it's a hope. And it's the most expensive option, because you pay at the worst possible moment — when the site is already down, customers can see it, and you have neither a diagnosis nor a person who knows the system.

Where to start this week

If you have a website and you're not sure which camp you're in, answer five questions: Who finds out first if the site goes down on a Saturday? When was a backup restore last tested — not performed, tested? Who is responsible for security updates, and when was the last one? Is the contact form working right now — have you checked this month? Who looks at the analytics, and when did they last lead to a concrete change?

If the answer to two or more of these is "I don't know," your website is a project slowly turning into a risk. The good news: moving to an operational model doesn't require a new website. It requires deciding whose responsibility it is — and then the discipline to stick to that decision.

Want to talk about what's covered here? Get in touch →