Every client’s goal — and understandably every developer’s too — is to have digital platforms running at peak efficiency, equipped with the latest features. The reality, however, is that a website requires significant behind-the-scenes work just to maintain the status quo, even if it hasn’t shown any visible updates for months.
First and foremost, a website runs on a web server that must be continuously monitored and maintained. This ensures it remains protected against potential attacks and can be swiftly restored in the event of a malfunction. A watchful eye must constantly be kept on memory, disk space, and incoming traffic, which is increasingly driven by aggressive web crawlers and AI agents. Routine tasks include creating and managing backups, which provide a reliable fallback to a previous state should issues arise or if a content manager accidentally deletes data. Security is an entirely separate chapter, beginning with the ongoing management of SSL/TLS certificates.
Security updates are frequently necessary. These are critical operations that cannot be postponed, requiring a comprehensive review of the website to guarantee that everything works exactly as before, despite the underlying changes. Inevitably, occasional tests will fail, indicating that one or more features have temporarily broken and need to be patched. Ultimately, even maintaining what has already been delivered to the client requires ongoing work — and consequently, additional costs that aren’t always easy to explain. All of this must be accomplished without the luxury of taking the site down for days, or even hours, of maintenance.
Websites are often built on open-source CMS (Content Management Systems) developed by communities of programmers. A CMS acts as a skeleton, fleshed out by a myriad of available plugins that introduce specific functionalities (such as forms, widgets, etc.).
When a client requests a new feature, the developer typically implements it by installing and customizing an existing plugin (because, as experience dictates, an off-the-shelf module never perfectly matches a specific client’s needs) or, in more complex scenarios, by building a fully custom module from scratch. This is where the work visible to the client ends, and the behind-the-scenes effort begins: the newly installed plugin or custom code can easily conflict with pre-existing plugins and code, requiring careful troubleshooting to ensure all features coexist peacefully. This is an inherent risk in modular architecture; while it is the most efficient approach, it can result in an infinite and often unpredictable number of states, depending on the specific combination and versions of the plugins used.
This translates to additional hours of work just to restore what the client already had and had already paid for. The most embarrassing scenario is when a page completely breaks, but paradoxically, for a developer, this is often the most desirable outcome: it clearly highlights the error, providing a direct path to fix it. Far worse is a silent error that doesn’t manifest clearly or only surfaces months later, typically when a content manager activates a feature that hadn’t been used until that moment.
The communities behind these open-source CMS platforms periodically release new versions to patch bugs and introduce new capabilities. Naturally, the client immediately wants the best of what’s available.
But does it make sense to install a major update immediately? Almost certainly not. When a new CMS version drops, the majority of plugins won’t yet have a compatible update available. It is better to be patient, optimizing the workflow while minimizing costs and risks. Regardless, upgrading the CMS requires reviewing all custom modules, which are also at high risk of breaking on the new platform. Once again, this is substantial work performed simply to maintain what already exists.
This raises a legitimate question: does building a website entirely in-house, bypassing a CMS and its plugins, eliminate these problems? Not really. If anything, it merely shifts the burden from a massive global community onto the shoulders of a much smaller internal development team, who are then tasked with handling all development and testing, ultimately increasing both costs and risks.
Our perspective
These reflections come from our day-to-day work. At COMMpla, we build and maintain websites and platforms on open-source CMS, and the scenarios described above are ones we deal with regularly: security updates that need full regression testing, plugins that stop working together after a routine update, and major CMS releases that are best adopted only once the surrounding ecosystem has caught up.
Our approach is to treat maintenance as a planned, ongoing activity rather than an emergency response. In practice, this means monitoring servers and backups continuously, applying security patches promptly, testing updates in a staging environment before they reach the live site, and scheduling major upgrades once the plugins and custom modules a site depends on are ready. We also try to make this work visible to our clients, so the effort behind a site that “looks the same” is clear and can be planned and budgeted.
If you manage a website and want to understand what keeping it secure and up to date involves, get in touch with our team.
Massimo Berutto | Senior Software Developer