Launch is the start of the obligations, not the end
A website is usually budgeted as a project: a design phase, a build phase, a launch. That framing is accurate about the money spent up front and misleading about everything after, because the day a site goes live is the day it starts depending on software maintained by other people.
Those dependencies keep moving. A platform releases a security update. A plugin is abandoned. A browser changes how it treats a cookie. None of these are caused by anything the site did, and all of them require someone to notice and respond.
The failures that do not announce themselves
The most common serious website problem we are asked to look at is a contact form that has not delivered an enquiry in weeks. Nothing about the page looks wrong. The form submits, the confirmation appears, and the message goes nowhere — usually because a mail credential changed or a spam filter began rejecting the sender.
The same pattern applies to expired API credentials, a payment webhook that stopped being accepted, and an analytics tag removed during an unrelated edit. Each is invisible on the page and consequential to the business, which is why routine verification of the paths that matter belongs in a maintenance arrangement rather than in someone's memory.
Certificates and domains are small tasks with large failure modes
A TLS certificate that lapses takes the whole site down with a browser warning that frightens visitors, and a domain that lapses can be very difficult to recover. Both are cheap to manage and disproportionately damaging to forget.
Automated renewal handles most of this, but automation fails quietly too — a DNS change can break a validation method that has worked for years. Monitoring expiry independently of the renewal mechanism is what turns a potential outage into a warning email.
Content drifts away from the business
Separately from the technical work, a site slowly stops describing the organization it represents. Services change, positioning sharpens, a page written for a smaller company stays online. No single edit is urgent, so none of them happen.
This is why we treat a predictable route for small content changes as part of maintenance rather than as favours arranged individually. When updating a page is a known, cheap process, it happens; when it requires a quote, it does not.
Budgeting for it honestly
The useful question is not what maintenance costs in the abstract but what an outage costs this particular business, and how quickly it would be noticed without monitoring. A brochure site and a site that generates most of a company's enquiries deserve very different arrangements.
What both deserve is an explicit answer rather than the default one, which is that nothing is maintained until something visibly breaks.
It also helps to separate the two kinds of spend. Keeping the site working — updates, monitoring, renewals, verification — is a running cost with a fairly predictable shape. Changing what the site says or does is project work with its own justification. Bundling them into one number tends to make the running cost look discretionary, which is how it ends up cut.
Dependency currency is cheaper than dependency debt
Platform and plugin updates are easy to defer because skipping one has no visible consequence. The cost arrives later and non-linearly: a site two minor versions behind is a routine upgrade, and one three major versions behind is a migration project with compatibility work attached.
The same applies to the language runtime underneath. A PHP or Node version reaching end of life stops receiving security fixes whether or not anything about the site has changed, and hosting providers eventually remove it, which converts a scheduled upgrade into an unscheduled outage.
Keeping current is not about having the newest of everything. It is about never being so far behind that the next necessary step is large enough to need its own budget approval.
Backups only count once a restore has been tried
Most sites have backups configured. Considerably fewer have had a restore performed, timed, and checked against what the restored copy actually contains — which is the only way to know whether the backup covers the database, the uploaded files, and the configuration, or only one of the three.
An untested backup is a reasonable hope rather than a recovery plan, and the moment you discover the difference is the worst possible moment to discover it. A restore rehearsal also produces the number nobody has otherwise measured: how long getting back would actually take, which is the figure any conversation about acceptable downtime depends on.