Keeping a site working after everyone has moved on
Maintenance keeps a live site secure, current and working: applying updates, verifying backups restore, monitoring uptime and performance, and providing a route to get something fixed. It is the phase where most sites are neglected, and where most avoidable failures originate.
A website is launched with attention and then left alone. Updates are deferred because the site is working. Backups are configured and never tested. Monitoring is assumed to exist. Then something breaks on a Friday evening, and the business discovers it has no support arrangement, no recent backup it trusts, and no idea who to call.
Neglect produces a specific and predictable sequence. Unapplied security updates accumulate until one is exploited, outdated plugins and dependencies are among the most common routes to a compromised site. Backups run to the same server that fails. SSL certificates expire, because renewal was manual and the person who did it left. Nobody notices the contact form stopped delivering three weeks ago, because nobody was testing it and enquiries simply stopped.
When this work makes sense
Questions worth asking any supplier
When was a backup last restored successfully? An untested backup is an assumption rather than a safeguard.
Who applies security updates, and how quickly after release?
Is anything monitoring uptime and form delivery, or do you find out from a customer?
What is the response path outside working hours, and what does it actually cover?
Who holds hosting, domain and DNS access? Missing credentials turn a small incident into a long one.
Deliverables
Scheduled updates for platform, plugins and dependencies, applied on staging before production
Automated backups stored separately from the server, with periodic restore tests
Uptime, SSL expiry and form delivery monitoring with alerts
Security monitoring and hardening appropriate to the platform
Performance checks against the agreed budget, so regressions are caught
A defined support route with agreed response expectations
An access and credentials register, so nothing depends on one person's memory
Regular reporting on what was updated, what was found and what was fixed
Built with
Process
Maintenance here begins by restoring a backup, before anything else. Most clients believe they have working backups; a meaningful proportion have backups that fail to restore, are missing the database, or write to the same server they are meant to protect. Proving recovery works is the first deliverable, because every other safeguard assumes it.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Ad hoc fixes, a maintenance plan, or managed hosting
Ad hoc
Fits: Simple static sites that rarely change and carry little risk
Limits: Nothing is monitored, so problems are found by customers; no relationship in place when it matters
Maintenance plan
Fits: Most business sites, particularly on platforms needing regular updates
Limits: Monthly cost for something that ideally produces no visible events
Managed hosting
Fits: Businesses wanting infrastructure and platform handled together
Limits: Covers the server; application-level issues and content usually remain yours
Case studies
No published maintenance case study. The measure of this work is the absence of incidents, which does not photograph well.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
Do we really need maintenance for a simple site?
It depends on the platform. A static site with no dependencies needs very little. Anything on WordPress or with a package dependency tree needs updates, because vulnerabilities are found continuously and unpatched components are the most common route to a compromised site.
Our host says they back everything up.
Many do, and the questions worth asking are how far back, how quickly you can restore, and whether anyone has tested it. A backup nobody has restored is an assumption. We test restores rather than trusting the dashboard.
What happens if the site goes down at the weekend?
That depends on the arrangement, and it should be agreed before it happens rather than negotiated during an outage. We set response expectations explicitly, including what is and is not covered outside business hours.
Can you maintain a site you did not build?
Usually. We would review it first, because inheriting an undocumented site carries real risk and we would rather assess it honestly than quote blind. Sometimes the honest answer is that remediation is needed before maintenance is meaningful.
How often should updates be applied?
Security updates promptly. Feature updates on a schedule, tested on staging first. Applying everything immediately to production is how a working site breaks on a Tuesday morning for no business reason.
Our contact form stopped working and nobody noticed.
Extremely common, and usually caused by a mail configuration change, an expired API key or a spam filter. It is also entirely preventable, an automated test submission on a schedule catches it within a day rather than within a quarter.
What is not included in maintenance?
New features, design changes and content rewriting are separate work, and the boundary should be written down. Maintenance keeps what exists working, updates, backups, monitoring, fixing things that break. The common dispute in maintenance arrangements is whether a request is a fix or a change, so we define that in the agreement rather than leaving it to a conversation during an incident.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.