When a website goes live, most clients feel a sense of relief, as if the project had just closed. In reality, this is where the phase begins that determines whether the site will still serve the business well in five months or five years. That phase is ongoing development support, and it's widely misunderstood, because many people assume it simply means having someone to call when something breaks.
Website support isn't only bug fixing: its purpose is the continuous technical maintenance of the site, the reduction of operational risk, and the organised handling of smaller operational and change requests.
For us, ongoing development support is usually made up of several elements. Depending on the support package and the scope agreed for the given system, it can include monitoring, preventive maintenance, handling security updates, resolving errors, and taking care of the smaller day-to-day changes, all of it carried out by a development team that knows the site's architecture and the decisions behind it. The goal isn't to put out a fire quickly, it's to have as few fires as possible.
What clients think support is, and what actually happens
Most business leaders equate support with troubleshooting: if a button stops working or a page shows a white screen, they call the developer, who fixes it. That picture isn't wrong, it's just very incomplete, because the bulk of the work never reaches that point, since someone prevented the problem earlier.
A website isn't something you build once and then leave standing still, it's a constantly moving system. The WordPress core is updated regularly, new plugin versions close security holes, and visitor habits shift month by month. Browsers, third-party services, APIs and the components the site relies on all keep changing, which means a system that was stable a year ago still has to be kept compatible. If no one follows that movement, the site doesn't break from one day to the next, it slips out of your hands slowly and unnoticed.
What visitors never see, but without which everything falls apart eventually
Most of ongoing support stays deliberately invisible, since the whole point is that the visitor never has to notice the work behind it. That includes regular plugin updates, carried out in a controlled way, weighing compatibility and business risk: an update touching a payment or booking flow is treated differently from a minor visual change. On WordPress-based systems this typically means tracking the state of the core and the plugins and handling the updates they need, while on custom systems the maintenance of the technology components, dependencies and integrations in use tends to take priority.
It also includes the maintenance of the security layers: depending on the system and the support package, that can mean reviewing security settings, handling the necessary updates, and responding to identified technical or security risks, so that a long-neglected component doesn't become an entry point for an attack. A neglected website becomes a more attractive target over time, not because the technology got worse, but because more and more known, documented vulnerabilities accumulate around it with no one closing them.
On WordPress-based systems this extends to following major core version changes. A larger core update, of the kind seen during certain phases of the Gutenberg rollout, can fundamentally change how the editor behaves or how a custom-built block works. If no one tracks that deliberately, the problem surfaces at exactly the moment that suits you least.
What happens when something really does break
However thorough the prevention, a third-party API can change without warning, a hosting provider can run into trouble, or a plugin update can have an unexpected side effect. The question in those moments isn't whether every error could have been avoided, it's how quickly and how thoroughly someone responds who already knows the site's full architecture.
A setting that can be toggled in a third-party service's interface sometimes only appears to take effect, while the actual behaviour is driven by logic at code level in the background. A developer unfamiliar with the system often spends hours working that out, whereas a team that knows the architecture and the earlier decisions behind it knows far sooner where to look for the real control.
The monitoring that prevents the problem
One of the least visible and most valuable layers of ongoing support is monitoring. Uptime monitoring flags when the site becomes unreachable, while performance monitoring tracks the metrics that shape both the experience a visitor gets and how satisfied the search engine is with the site.
The latter matters in particular, because website performance isn't a fixed state, it's a moving target. A form or an external integration can look technically functional while some element of the process behind it fails silently. Appropriate monitoring and regular checks can help catch problems like these earlier.
Small requests that aren't projects, but still take time
There's a layer of the work that is neither troubleshooting nor new development, it's the small, continuous adjustment of everyday life. Fixing a typo in a product description, uploading a photo of a new colleague, swapping a seasonal banner, adding a form field. Individually these look trivial, together they demand constant attention, and they're exactly the kind of requests that either get lost or wait for weeks in a poorly organised support relationship.
It's worth drawing a clear line between what belongs in support and when a request becomes a development task in its own right. Support typically covers what stays within the logic of the existing system and needs no new design work. As soon as a request calls for a new feature, a more significant architectural decision or a change spanning multiple pages, it becomes a separate development task with its own scope and estimate. Whether a specific task can be handled within support is determined together by the service scope of the given support package, the available allowance, and the complexity of the request.
In a well-run support system every request has a clear path: incoming requests are logged, prioritised, and handled according to the process and terms set out in the support agreement. The client doesn't have to keep track of a dozen small requests, because the system does it for them.
What happens behind the scenes in an average month
Depending on the support package and the system, a month can involve tasks such as these:
Monitoring. Depending on the support package and the scope agreed for the given system, this can cover uptime, performance and security alerts.
Checking updates and risks. On WordPress-based systems this typically means tracking the state of the core and the plugins and handling the updates they need, while on custom systems the maintenance of the technology components, dependencies and integrations in use tends to take priority.
Handling incoming requests. Receiving and prioritising smaller change requests.
Necessary corrections. Fixing the identified risks or errors, weighing compatibility and business impact.
Reporting back. Letting the client know what happened in the background, and what is still waiting to be resolved.
This is the cycle the client ideally never sees, precisely because it works.
Why a "call us in an emergency" contract isn't enough
Plenty of companies assume it's enough to have a number to call when something goes wrong. That model does work for a while, right up until an error hits at a moment when no one is available, or until it turns out that the root of the problem lies in an update quietly missed months earlier.
Ongoing support, by contrast, isn't built on having someone to call, it's built on needing to call someone as rarely as possible. The emphasis is on prevention rather than firefighting, and that difference is what significantly reduces both risk and unexpected cost over the long run.
For a business-critical website this stops being a matter of technical convenience and becomes a business continuity question. If part of your sales or lead generation runs through a site, the stability of that system is as much a risk management item as any other critical business system.
Common misconceptions about development support
The most common misconception is that support is only worth something when something is actually happening. That's like thinking insurance is only useful if you make a claim, when in fact the best month is the one where nothing happens, because everything is where it should be.
The second is that postponing updates carries no risk, since the site works fine right now. In reality a missed security update can leave a known vulnerability open, sustained version lag can increase both compatibility and security risk, and past a certain point catching up takes far more work than continuous maintenance would have taken in total.
The third is that support and development are two separate worlds. In reality the best ongoing support works precisely because the same team, or the same knowledge base, sits behind it as the one that originally built the site, so every decision is made in familiar context rather than groping around in an unfamiliar system.
The W5labs approach
For us, Support doesn't join a project after the fact. From the outset it's the fourth layer of the system, alongside Strategy, Creative and Development. On systems built by W5labs there's an added advantage: the same technical knowledge and project familiarity built up during development sits behind the support work. On systems taken over from another developer, a technical discovery and familiarisation phase can lay that same groundwork.
This has a direct business benefit. An external support partner has to understand an unfamiliar system in every emergency before they can start troubleshooting, and that time costs money. On systems built by W5labs this step typically disappears, because the same team or the same knowledge base handles the request as the one that built the site. On systems taken over from another developer, early technical familiarisation reduces that lost time for future cases.
In practice this means regular update cycles, continuous security and performance monitoring that helps identify certain problems and risks earlier, and a clear channel for smaller requests, which we handle with prioritisation and feedback along the way.
This kind of continuous presence helps a website keep running stably, securely and in step with a changing technology environment over the long term, not because nothing around it changed, but because someone kept adapting to those changes on your behalf.
The exact content and terms of W5labs' support service depend on the given website, support package and agreement. In every case our aim is the same: predictable development and technical backing behind websites that matter to the business.
