A website is not a brochure that stays printed. It is software running on a server, built on other software, connected to other people's software — all of which keeps changing after you stop looking at it.

Launch day is not the finish line. It is the moment the site starts ageing, and maintenance is the thing that stops the ageing turning into an incident.

The awkward part of selling maintenance is that when it is working, nothing happens. There is no output to show. So here is what is actually being done, and what each item turns into when nobody does it.

Security patches

What it is: keeping the software underneath your website on versions that still receive security fixes, and applying those fixes promptly when they are published.

Your site sits on a stack: the operating system, the web server, the PHP or Node runtime, the database, and your application's own dependencies. Vulnerabilities are found in all of them, continuously. When one is found, a patch is released — and a released patch that nobody applies protects nobody.

This is not theoretical. In October 2026 two critical remote code execution vulnerabilities were patched in PHP itself, with fixes released the same day for four supported branches and nothing at all for the branches that had reached end of life. Within five days both identifiers were in CISA's catalogue of exploited vulnerabilities. Every PHP site in the world needed attention that week, and most of them did not get it.

What it involves in practice: knowing which versions you run, watching the advisories for those specific components, assessing whether each one applies to you, and applying the ones that do with a backup and a test afterwards.

What happens without it: the window between a public advisory and automated exploitation is now days. Automated scanning finds unpatched sites far faster than a human would, and it does not care how small your business is. The eventual outcome is not usually a dramatic defacement — it is your server quietly sending spam, hosting someone else's phishing pages, or exfiltrating your customer records.

Dependency updates

What it is: updating the libraries your application is built from.

A modern application depends on dozens of packages, each with its own release schedule and its own occasional security advisory. Keeping them current is an ongoing trickle of small work.

The reason to do it steadily rather than annually is arithmetic. A library updated every few months moves one minor version at a time, and each step is small. The same library left for three years is four major versions behind, each with breaking changes, and the upgrade is now a project. Deferred dependency work does not stay the same size — it compounds.

What happens without it: eventually an advisory arrives for a package you cannot update without breaking the application, and you have to choose between a known vulnerability and an unplanned refactor.

Backups — and restores

What it is: copies of your files and database, taken automatically, kept somewhere else, and tested by actually restoring them.

That last clause is the whole thing. In our experience the most common serious finding when we take over an existing site is not an unpatched version. It is backups that have been silently failing, or that exist but have never been restored and turn out to be incomplete — database but not uploads, or a dump taken while writes were in progress.

A reasonable arrangement: automatic daily backups, retained long enough to cover a problem you did not notice immediately (a month is a sensible minimum, because data corruption is often discovered weeks later), stored somewhere other than the server being backed up, and a restore performed periodically to prove the whole chain works.

What happens without it: everything else on this list is recoverable. This one is not. A site with no working backup, after a failure or a compromise, is rebuilt from whatever anyone happens to have.

Uptime monitoring

What it is: something checking that your site responds, from outside your own network, and telling a human when it does not.

The baseline is cheap and worth having immediately: an external check every few minutes, alerting by email or phone. Beyond that, two things are worth monitoring that basic uptime checks miss:

  • Certificate expiry. An expired TLS certificate makes a working site unreachable, with a browser warning that frightens visitors. It is entirely preventable and still happens constantly.
  • Whether the site is working, not just responding. A page that returns HTTP 200 with a database error in the body passes an uptime check. Monitoring a specific element on a specific page catches this.

What happens without it: you find out from a customer. The gap between an outage starting and anyone noticing is, for most unmonitored sites, measured in hours — and overnight or over a weekend, considerably longer.

Server maintenance

What it is: the operating system and services underneath the application — security updates, disk space, resource usage, log rotation, and the configuration that drifts.

Mostly undramatic, with one failure mode that catches people out: disk space. Logs grow, backups accumulate locally, caches fill. A server that runs out of disk does not degrade gracefully; the database stops accepting writes and the site fails in confusing ways. It is trivially preventable with a threshold alert and completely baffling if nobody is watching.

On managed or shared hosting, much of this is your host's responsibility — worth confirming exactly which parts, because the division is rarely as complete as people assume. "Managed" frequently covers the operating system and not your application's dependencies, and almost never covers whether your backups restore.

Performance checks

What it is: periodically measuring whether the site is still as fast as it was.

Performance regresses on its own. A new tracking script, a plugin update, a marketing page with an uncompressed hero image, a database table that has grown enough for a missing index to start mattering. None of these announces itself, and all of them accumulate.

A quarterly check is enough for most sites: field data in Search Console, PageSpeed Insights on the pages that matter, and a look at whether anything new is being loaded. We cover what to measure and which fixes earn their place separately.

What happens without it: a site that was fast at launch is slow two years later, nobody can point to when it changed, and the diagnosis is now an archaeology exercise across dozens of small changes.

Compatibility testing

What it is: checking that the things outside your control have not broken something.

Browsers update every few weeks. Payment providers deprecate API versions. Third-party services change their terms. Mobile operating systems change how they handle cookies, autofill or scrolling. None of these consults you first.

The practical approach is not continuous: it is a periodic pass through the flows that matter — checkout, booking, contact, login — on current browsers and a real phone, plus reading the deprecation notices from your payment and email providers when they arrive, because those have deadlines attached.

What happens without it: the classic version is a checkout that has been failing on one browser for five weeks, discovered when someone finally emails to complain rather than simply leaving.

Incident prevention versus incident response

The distinction that decides the cost.

Prevention is everything above: patch, update, verify backups, monitor, check. Routine, plannable, and modest.

Response is what happens when prevention did not: a compromised server, a failed restore, a payment flow that has been broken for a month, a site down over a bank holiday. Urgent, out of hours, unbudgeted, and frequently involving data loss or customer-facing consequences that no amount of engineering recovers.

Response work is more expensive than prevention work by a wide margin, and it buys you nothing — at the end of it you are back where you started, minus the time and the customer goodwill. That is the entire commercial argument for maintenance, and it is not an exaggeration that the first serious incident usually costs more than several years of the prevention that would have avoided it.

Technical support

Separate from maintenance, and often bundled with it: someone reachable who understands your system when something is wrong or something needs changing.

The value is mostly in continuity. A developer who built the application, or has maintained it for two years, diagnoses a problem in an hour. A new contractor meeting the codebase for the first time spends that hour working out how it is structured — and charges you for it.

Worth agreeing explicitly: what counts as an emergency, expected response times, and whether small changes are included or billed. These are easier to settle before anything is broken.

The long-term cost of ownership

The number people plan with is the build cost. The number that matters is what the thing costs over five years.

A realistic annual picture for a business website or application:

  • Hosting: modest, and predictable.
  • Domain and TLS: negligible.
  • Third-party services: payments, email delivery, maps, monitoring. Individually small, collectively worth listing.
  • Routine maintenance: patching, updates, backup verification, monitoring, periodic checks.
  • Small changes: text, prices, a new page, a tweak to a form. Continuous and underestimated.
  • Periodic larger work: a runtime upgrade, a dependency major version, a redesign of one section. Every couple of years.

For an actively used custom application, planning on 15% to 25% of the original build cost per year for maintenance and small changes is a realistic figure — lower for a simple brochure site, higher for something with many integrations. That is a planning heuristic rather than a quote, and the point of stating it is that budgeting zero is the common alternative, and zero is wrong by a larger margin than any reasonable estimate would be.

Deferring that spend does not avoid it. It converts a predictable annual cost into an unpredictable larger one, usually at the worst moment.

What a sensible arrangement looks like

Not a long contract. A short, clear one:

  • Monthly: security patches applied, backups verified, monitoring reviewed, uptime checked.
  • Quarterly: dependency updates, a performance check, a pass through the critical flows on current browsers and a real phone.
  • Annually: runtime version review, a restore test performed end to end, a look at whether any third-party dependency has become a risk.
  • As needed: security advisories affecting your specific stack, acted on when they are published rather than at the next scheduled visit.
  • Always: somebody who knows your system and answers.

If you have a live site and genuinely do not know when it was last patched, whether its backups restore, or whether anyone would be told if it went down tonight, those three questions are worth answering this week. They are the whole of the risk, and they each have a short answer.

Our Technical Support and Maintenance service is built around exactly that list. If you would prefer to handle it yourself, the list above is still the list — the important thing is that somebody owns it.