Written byRedevon IT TeamManaged Operations
Website Maintenance Packages: What to Look For Before You Buy
On paper, most website maintenance packages look nearly identical. Three tiers, rising prices, a bullet list that reads about the same wherever you look. Updates. Backups. Security. Support. The differences look cosmetic.
In practice, two packages priced identically can deliver wildly different amounts of actual work. One provider pushes updates on autopilot and reviews nothing. Another tests every update on staging first and actually reads the changelog before it ships. Both call it "software updates" on the same line item.
The problem for a buyer is that this distinction is invisible at the point of sale, and only shows up months later — usually during an incident. This guide covers how maintenance packages are actually structured, what separates a real one from a nominal one, and how to compare two providers on equal footing.
For what these packages typically cost, see our companion guide on website care plan pricing. This article is about evaluating scope, not price.
How maintenance packages are structured
Most providers sell one of four commercial models. Knowing which one you're being offered matters more than the headline number, because it determines what actually happens the day you need something.
Hours-based. A set block of development time each month — two, five, ten hours, whatever's agreed — on top of the standard maintenance work. Rollover varies by provider. This is the most transparent model and the easiest to compare, because the unit being sold is explicit.
Task-based. A fixed list of what's included, with anything else quoted separately. Predictable for routine work, but the line between "included" and "extra" is where the friction lives. If you're being offered this model, the exclusion list matters more than the inclusion list.
Unlimited small changes. Content edits and minor tweaks aren't metered, as long as they fit the definition of "small." Looks great on paper, and works fine if the provider actually defines that threshold. If they don't, expect the definition to quietly tighten the longer you're a customer.
Retainer with allocated capacity. A monthly commitment that reserves part of the provider's team, used flexibly across maintenance, development, and improvements. More expensive, and the right call when the site is business-critical and your needs shift month to month.
None of these models is inherently better. The failure mode is buying one and expecting the terms of another — most often, signing a task-based package and then being surprised it doesn't flex like an hours-based one would.
What separates a substantive package from a nominal one
Seven things account for most of the real difference between providers. Check them individually — a package can be missing all seven and still call itself "maintenance" on the invoice.
Update testing. The biggest single differentiator. Ask directly: are updates tested on a staging environment before they touch the live site? A provider applying updates straight to production has automated the task without managing the risk. When a plugin update clashes with a theme — which happens on any site old enough to matter — that lands on your visitors, not on the provider.
Backup verification. Every package includes backups. Fewer include tested restoration. Silent backup failure is common, and it's discovered at exactly the moment you can't afford it. Ask when the restore process was last actually run.
Defined response times. "We aim to respond promptly" isn't a commitment, it's a hope. A real package states target response times, tiered by severity, in writing. An outage and a typo fix shouldn't get the same priority, and the agreement should say so.
Performance monitoring. Uptime monitoring is nearly universal now. Performance monitoring isn't. Sites get slower gradually as content and plugins pile up — without a baseline to measure against, that decline is invisible until it shows up in rankings or conversion.
Reporting. A monthly summary of what was done, what was found, what's recommended. Providers doing real work produce this as a matter of course. No report means you're trusting their word instead of seeing the evidence.
Named accountability. Whether you have someone who actually knows your site, or a generic support inbox routed to whoever's free. For small requests it barely matters. During an incident it matters a lot — nobody should be re-learning your setup while the clock is running.
Exit terms. What happens if you leave. Whether you keep your credentials, whether the documentation is current, whether a handover process even exists. Sort this out at the start of the relationship, not at the end, when goodwill is in shortest supply.
Comparing two packages on equal terms
Providers rarely present quotes in a comparable format, which makes evaluating two proposals side by side harder than it should be. The table below normalises them. Run two quotes through it and you'll usually find the cheaper one is cheaper for specific, identifiable reasons.
| Question | What to record | Why it matters |
|---|---|---|
| Are updates tested on staging first? | Yes / No | The largest single risk differential |
| Are backups restore-tested? | Frequency | Untested backups have failed silently before |
| Response time for a critical outage? | Hours, in writing | Distinguishes commitment from aspiration |
| Out-of-hours coverage? | Included / Extra / None | Determines behaviour at 2am on a Sunday |
| Development hours included? | Number, and rollover terms | Usually the largest cost variable |
| What falls outside the package? | The exclusion list | Where unexpected invoices originate |
| Is performance monitored? | Yes / No, and which metrics | Degradation is otherwise invisible |
| Is there a monthly report? | Yes / No — request a sample | Evidence versus assurance |
| Named contact? | Yes / No | Matters during incidents |
| Contract term and notice period? | Months | Long lock-ins warrant scrutiny |
Two quotes that look thirty percent apart on price often turn out to differ by a lot more than that in actual scope. And the more expensive option isn't automatically the better one — the table just makes the comparison honest.
Website support plans and maintenance packages
The terms website support plan, maintenance package, and website care plan get used interchangeably across the market, and there's no consistent industry definition separating them. There's a loose pattern, though:
- Support plan tends to lean on responsiveness — someone available when something needs attention.
- Maintenance package tends to lean on routine work — updates, backups, and monitoring done on schedule.
- Care plan tends to cover both, and is the term providers use most when they're selling continuity of relationship rather than a specific task list.
Don't rely on the label. If a proposal is called a "support plan," find out whether routine maintenance is actually included. If it's called a "maintenance package," find out what happens when you need help outside the schedule. Read the scope, not the name on the cover page.
Common problems
Four patterns show up in most of the dissatisfaction we hear about.
Automation dressed up as management. A scheduled update job and an automated backup, sold as a maintenance service. That's a legitimate product at a low price, and it's fine for a site with limited commercial stakes. It becomes a problem when it's bought expecting an actual human keeping watch.
Hours disappearing with no warning. If a package includes development time, get the rollover position in writing. Providers vary a lot here, and the terms often only surface after the first quiet month has already passed.
Scope arguments that never end. Common under the "unlimited small changes" model when "small" was never defined. Nail the threshold down at the start — most of these disputes come from ambiguity, not bad intent.
Reactive-only service. Some packages are built entirely around responding to reported problems, with nothing proactive attached. Nothing's monitored, nothing's flagged, issues get fixed once someone notices. That's worth a lot less than it sounds like in the sales pitch, because noticing is still your job.
Matching the package to what you actually need
The right tier follows from the site's commercial role, not its technical complexity.
If the site is mostly informational and going down would be an inconvenience rather than a cost, an entry-level package covering updates, backups, and monitoring is proportionate. You're unlikely to use allocated development hours much.
If the site generates enquiries or supports sales, a mid-tier package with allocated development time and defined response commitments is usually worth it. The development time is typically the part that pays for itself — small accumulated improvements add up to something measurable.
If the site processes transactions or downtime has a real cost, priority response, out-of-hours coverage, and proactive monitoring stop being optional extras. At that point you're comparing the package against the cost of an outage, not against a cheaper package.
A useful gut check: work out what four hours of downtime during business hours would actually cost you. If that number comfortably exceeds a year of maintenance, the package tier should reflect it.
Frequently asked questions
Software and dependency updates, backups stored off-server with a tested restore process, uptime monitoring, security scanning, and SSL certificate management. Below that bar, whatever you're being sold isn't really maintenance.
Hosting is the infrastructure your site runs on. A maintenance package is the ongoing work of keeping the site itself running well on top of that infrastructure. Managed hosting sits in between and sometimes includes bits of maintenance — don't assume, ask exactly what's covered.
Usually unlimited in how many requests you can make, not in scope. 'Unlimited small changes' is only as good as the definition of small — get that written down before you sign, not after the first dispute.
Depends on the provider. Some let hours roll over within a window, some don't allow it at all. Neither approach is wrong, but it should be spelled out in the agreement, not discovered the first time you don't use your hours.
Most providers will let you move tiers with some notice. If your needs are seasonal or you've got a big campaign coming, get the terms for adjusting up or down confirmed before you commit, not after.
Not necessarily. If the site is static, someone in-house already owns it technically, and it doesn't matter much commercially, managing it yourself is a reasonable call. Automated backups and a recurring review should still happen regardless.
The short version
Website maintenance packages are hard to compare because they're presented inconsistently, and because the things that matter most — update testing, backup verification, defined response times — are the least visible when you're buying.
Judge packages on the seven differentiators above, run competing quotes through the comparison table, and match the tier to the site's commercial role rather than its technical complexity. When two packages look similar on price, the real difference is usually in what wasn't mentioned.
At Redevon IT, ongoing platform care is the service we built the company around — we've been looking after clients' platforms since 2012. If you're comparing maintenance proposals, or taking over a site someone else walked away from, tell us what you're working with and we'll give you an honest read on what you actually need.
Journal
