What happens after launch: why ongoing maintenance determines long-term ROI

Most launched sites are at peak quality on the day they go live. From that day forward, they degrade. Not catastrophically, not visibly — quietly, in small accumulations, until one Tuesday morning six months later someone notices the checkout is broken or the homepage takes nine seconds to load and the question is: how long has it been like this?

The honest answer is usually weeks. Sometimes longer.

This isn't a hypothetical. We've audited dozens of sites that were lovingly designed, beautifully built, and then handed over to a client team that had no continuing relationship with the people who shipped them. Within sixty days, measurable degradation. Within six months, the kind of degradation that's costing real money — in lost conversions, in search visibility that's quietly slipped, in trust that erodes with every visitor who hits a glitch.

This piece is about why that happens, what proper maintenance actually involves, and how to think about the cost of doing it versus the cost of not.

What happens to your site after launch (if nothing is done)

Software is not a finished artefact. It's an ongoing system surrounded by other systems that move under it.

The first thing that goes is dependency drift. Every modern web stack — whether it's a Next.js app, a WordPress site, a Shopify theme, or a Webflow build — sits on top of a graph of libraries and platform versions that are being patched, updated, and occasionally deprecated by their maintainers. When you don't pull those updates in, two things happen. The version you're running gradually falls behind the security baseline, and the upgrade path gets harder every month you postpone it. The site that could have been updated in two hours in month one needs a two-day project in month nine, because by then three breaking changes have stacked up and your old plugin doesn't work on the new platform version.

Security vulnerabilities accumulate. Most public-facing sites are probed continuously by automated bots looking for known exploits in unpatched software. The vast majority of breaches in 2025 weren't sophisticated attacks — they were known vulnerabilities that the site owner hadn't got around to patching. The UK National Cyber Security Centre publishes the patterns. The pattern is: unpatched dependency, automated probe, breach within weeks. A site that's actively maintained closes those windows fast. A site that isn't doesn't.

Core Web Vitals degrade as third-party scripts accumulate. This is the slow killer. Marketing adds an analytics tag. Sales adds a chat widget. Compliance adds a cookie banner. Each is small. Together, by month four, your LCP has crept from 1.6 seconds to 3.4 seconds, your INP has doubled, and Google has quietly demoted you in the search results without ever telling you that's why. Most clients don't notice the cumulative impact because each individual addition felt minor at the time.

Content goes stale. Pages that referenced "our 2024 case study" still say 2024 in 2026. Team pages list people who left. Service pages describe offerings that have evolved. Links to external resources 404 silently. The internal cross-linking that supports SEO degrades because nobody's auditing it. None of this is dramatic. All of it compounds.

Analytics drift. Tags break when underlying pages are restructured. Events stop firing when CSS selectors change. The dashboards you built at launch keep producing numbers, but the numbers are subtly wrong — and the decisions you make from them get subtly wrong too. We've audited analytics setups where 40% of e-commerce events hadn't fired for months and nobody had noticed because the topline traffic number still looked roughly normal.

Maintenance is the line between an asset and a liability. Source: Pexels

The hidden costs of not maintaining

The honest accounting is uncomfortable, because the costs of not maintaining a site rarely arrive as a single bill. They arrive as a series of separate problems that each look like something else.

A security breach. The Cyber Security Breaches Survey 2024 puts the average direct cost to a UK SME at around £4,200 per incident, and that's just the immediate clean-up. The real costs — customer notification, regulatory response under UK GDPR, reputational impact, lost trading days — typically run 3 to 10 times that figure. A breach traceable to an unpatched dependency is the most preventable category of cost in the entire ledger.

A search ranking drop discovered too late. By the time you notice in Google Search Console that your impressions have halved, the cause is usually two or three months in the past — a Core Web Vitals regression, a crawl error, a sitemap that broke when content was migrated. The cost is the revenue you didn't capture in the months between the regression and the diagnosis, and the recovery time is usually similar. Three months of lost traffic to fix three months of degradation, and that's if you spot it cleanly.

A checkout bug discovered via revenue decline, not monitoring. The site that's quietly losing 8% of its purchases because of a Safari-specific JavaScript error introduced three weeks ago, where the team only notices because the monthly numbers come in soft. That's the single most expensive class of failure we see, because the bug compounds for as long as it goes undiagnosed. A proper synthetic transaction monitor would have caught it on day one. Without one, you catch it when the bookkeeper raises an eyebrow.

The pattern in all three is the same. The cost of the failure is at least an order of magnitude higher than the cost of the maintenance that would have prevented it. Maintenance is insurance against a tail risk that is, in fact, not very tail.

Updates tested in staging cost a tenth of updates discovered in production. Source: Pexels

What a proper maintenance plan includes

There's enormous variance in what "website maintenance" means when you ask different agencies. Some sell hosting and badge it as maintenance. Others sell a help-desk relationship with no proactive component. A real maintenance plan has roughly six elements.

Dependency and plugin updates, with testing. Not blind auto-updates that break the site in the middle of the night. A monthly cadence where updates are pulled, tested in a staging environment, regression-checked, and then pushed to production with a rollback plan. For a complex site this is several hours of work a month. For a simple one, less. The mistake is treating updates as a button you press; the work is in the testing, not the upgrade.

Uptime monitoring and alerting. Synthetic checks every few minutes from multiple regions, alerts on failure, and ideally synthetic transaction tests that walk a real path through the site (homepage, product page, add-to-basket, checkout step one) so you catch functional failures and not just "the server is up." When this exists, the team finds out about a problem before the client does. When it doesn't, the client finds out from a customer email.

Monthly performance review. Core Web Vitals tracked over time, Lighthouse audits run on key pages, crawl health checked in Search Console, server response times benchmarked. The output is a short written summary with anything that's drifted and what's been done about it. This is the single highest-leverage line item in the plan, because it's where slow degradation gets caught before it compounds into a ranking problem.

Security scanning. Automated scans for known vulnerabilities in the dependency graph, monthly review of audit logs, periodic checks for unauthorised access patterns. Plus a defined response policy: who gets called, in what order, when the alarm goes off at 03:00 on a Sunday.

Content and link audit. Quarterly check for broken links (internal and external), pages that reference dates, team members, products, or partners that have changed, and orphaned pages that have lost their internal links. This is unglamorous work. It's also the work that keeps the site from feeling slightly off as the months pass.

Analytics QA. A monthly check that the events you care about are still firing, the conversion goals still converting, the funnels still tracking end-to-end. Tag managers drift. Selectors break. The dashboards keep producing numbers. Someone has to confirm those numbers are still real.

That's the floor. Everything else — A/B testing infrastructure, ongoing SEO work, feature development, content production — sits above the maintenance line as separate work, sensibly priced separately.

Uptime monitoring is cheaper than the email you'll otherwise get on a Sunday. Source: Pexels

DIY versus agency maintenance: an honest answer

You can do some of this yourself. Whether you should depends on what's already on your team's plate and how the maths works out on opportunity cost.

What's reasonable to handle in-house if you have a competent product team: content audits, link checks, copy updates, simple CMS work, light analytics QA if you have someone who understands the tag manager. Anything content-side, basically.

What's harder to do well in-house unless you have dedicated engineering capacity: dependency updates with proper testing, performance optimisation, security scanning beyond running a scanner, debugging a regression that only appears on Safari iOS, restoring from backup when the worst happens. This is real engineering work. If your team isn't doing engineering already, it'll be inefficient.

The honest cost comparison is rarely "agency maintenance vs free." It's "agency maintenance vs the time your team spends on it plus the things they don't catch." For most SMEs, an agency plan of one or two days a month is cheaper than the equivalent internal capacity, and substantially more thorough than the in-between option of "we'll deal with it when something breaks."

There's also a category mistake worth naming. Hosting isn't maintenance. A managed hosting plan keeps the server up. It doesn't update your dependencies, fix your Core Web Vitals, audit your content, or notice when your checkout has been broken for a week. Those are different jobs.

The compounding effect

The most useful way to think about maintenance is as a compounding cost question. Small consistent investment vs large irregular emergencies.

A month of competent maintenance on a mid-complexity site is roughly one day of senior time. Whether you pay that internally or through an agency, the all-in cost lands in the same range: a few hundred to about £1,200 a month depending on scope and stack complexity.

The cost of the avoidable failures runs in five figures, sometimes higher. An emergency response to a breach starts at around £8,000 once you've factored in forensics, communication, and the developer time to patch and harden. A recovery from a Core Web Vitals-driven ranking drop is typically £6,000 to £15,000 of dedicated optimisation work, plus the lost revenue during the recovery window. A serious checkout regression in a busy e-commerce site can cost five figures in a single weekend if it isn't caught quickly.

Over a 24-month horizon, the maintenance budget is almost always smaller than the expected cost of the incidents it prevents. The difficulty is that the maintenance is visible and the prevented incidents are invisible, so the budget conversation always feels like an argument about an expense rather than the risk-adjusted insurance position it actually is.

🎬 Watch: What ongoing care actually looks like

Quiet, planned work — the kind that prevents the loud, unplanned kind.

How the Nexus Sustain plan works

For our build clients, we offer an ongoing plan called Sustain. It's roughly one day of senior time per month, covers every element listed above, and starts the month after launch. The cost is flat, the scope is written, and either side can end it with 30 days' notice.

What's in it: dependency and plugin updates with regression testing, uptime and synthetic transaction monitoring, monthly performance and CWV review with a written summary, security scanning and patch response, quarterly content and link audit, analytics QA. Plus a small envelope of discretionary hours we can use for the inevitable small change requests — moving a button, updating copy, adding a tracking event — without raising a separate change order.

What's not in it: net-new feature development, multi-week optimisation projects, content production. Those run as separate engagements when needed. The point of Sustain is to keep the site at the quality you launched with, not to be a permanent retainer for unbounded work.

It's optional. Some of our clients take it, others handle maintenance in-house. We're transparent about which clients we think genuinely need it (anyone with a complex stack, an e-commerce flow, or a meaningful traffic level) and which can reasonably get by without (low-complexity marketing sites with internal developer support).

Talk to us

If you're approaching launch and haven't yet thought about what happens the day after, we can walk you through the options on a 20-minute call. If you've already launched and you're seeing some of the patterns described above — performance drift, a content audit overdue, the unsettling sense that things are quietly slipping — we can audit your site and tell you what's actually going on before recommending anything.

Get in touch about the Sustain plan.

FAQ

How much should website maintenance cost in the UK?

For a typical mid-complexity SME site, expect £400–£1,200 per month for a real maintenance plan that includes dependency updates with testing, performance monitoring, security scanning, and content QA. Plans under £200/month are usually hosting plus light help-desk, not maintenance. Plans above £2,500/month are usually bundling significant ongoing development work, which is fine if you need it but isn't strictly maintenance.

Can I just run automatic updates and skip the plan?

For very simple sites, sometimes. The risk is that auto-updates occasionally break things, and without a testing layer and rollback plan, you find out from a customer rather than a monitor. The bigger problem is that updates are the smallest part of the work. Performance drift, security scanning, content audits, and analytics QA aren't things you can automate, and those are where most of the value of a proper plan sits.

What's the difference between maintenance and a retainer?

A maintenance plan keeps the site at the quality level it launched at: same performance, same reliability, same content freshness, same security posture. A retainer typically includes those things plus an ongoing pool of hours for new work — design changes, feature additions, content production, optimisation experiments. Retainers cost more and are usually structured monthly. Maintenance is narrower and cheaper. We offer both, and we'll tell you which one you actually need rather than upselling you the bigger one.