Skip to content
Maintenance & Support

What a website maintenance plan should actually include

Most maintenance retainers bill for watching a dashboard. What a plan should cover, what it should cost, and the clauses worth refusing to sign.

4 min read
What a website maintenance plan should actually include. An article by Athabasca Solutions.

Maintenance is the least glamorous line on any web invoice and the one most likely to be quietly worthless. A plan that costs $150 a month and consists of somebody glancing at an uptime dashboard is not maintenance. It is a subscription to the idea of maintenance.

Here is what the money should actually buy.

The four things that are non-negotiable

Updates applied, on a schedule, with somewhere to test them. Not “we monitor for updates.” Applied. On a WordPress site that means core, plugins and themes monthly. On a custom application it means dependency updates and platform version bumps. And it means a staging copy, because an update applied straight to production on a Friday is not maintenance either.

Backups that have been restored. A backup nobody has restored is a file somebody hopes is good. The plan should include a restore, performed on a real schedule, with the time it took written down. That number is your actual recovery time and it is usually two to three times what people assume. This is worth its own attention, which is why it has its own article.

Monitoring that reaches a human before a customer does. Uptime, yes, but also the certificate expiry, and the contact form. Silent form failure is the most expensive small bug on the web: the site is up, the pages load, and the enquiries have been going nowhere for six weeks.

A named person and a stated response time. Not a ticket portal that promises “we aim to respond.” A name, a number, and a commitment you could hold someone to.

What should be in there but usually is not

  • A block of included hours. Two hours a month for content edits and small changes turns “can you just change the phone number” from a quote into a reply. Without it, every trivial change becomes a negotiation and eventually you stop asking, and the site goes stale.
  • An annual dependency and licence review. Things go end-of-life quietly. A yearly look at what is unsupported is how you get warning before an urgent migration.
  • A quarterly written note. Two paragraphs: what was updated, what broke, what is coming. It takes ten minutes and it is the only evidence the retainer is doing anything.
  • Your credentials staying yours. The domain, the host and the repository should be in accounts you own, with your supplier added as a user. Suppliers holding the domain is the single most common way a business gets stuck.

What you are probably overpaying for

Security scanning as a headline feature. Automated scanners produce long reports that mostly restate that you are running software. Applying updates prevents far more than scanning detects.

“Unlimited support.” It is not unlimited, and pricing it that way means the supplier’s incentive is for you to ask for as little as possible.

Performance reports nobody reads. A monthly PDF of Lighthouse scores is output, not work. If nothing changes as a result, it is padding.

Hosting bundled at a markup. Perfectly reasonable if the plan says so. Less reasonable when a $5 host is billed at $80 and described as “enterprise infrastructure.”

What it should cost

For a small business marketing site, a real plan is a modest monthly figure, and the honest version of that number depends almost entirely on what the site is built on. A static site needs very little: there is no database to patch and no plugin to conflict, so the plan is mostly monitoring and a couple of included hours. A WordPress site with a dozen plugins needs genuine monthly attention, and the plan costs accordingly.

That difference is worth knowing before you choose a platform, not after. Static versus WordPress goes through the running-cost side of it properly.

For an application with users and data, maintenance is a different conversation, because the failure modes involve somebody’s records rather than a marketing page.

The clause to refuse

Any plan that makes your site harder to leave. If the contract says the site is built on a proprietary platform you cannot export, or that the code is licensed rather than yours, that is not a maintenance plan, it is a lease with a maintenance label on it.

You should be able to end a maintenance agreement and keep the site. If you cannot, the plan was never the product.

The test

Ask your current provider two questions: when was the last time a backup was restored, and what changed on the site last month.

If both answers are vague, you are paying for availability rather than maintenance, and you can probably buy the same thing for less or get real work for the same money.

If you have a site nobody has looked after for a while and you would rather someone just took it on, tell us what it runs on and who built it. Inherited sites are most of what we take over.

Related: what hosting actually costs, inheriting a site nobody maintained, and our maintenance and support work.

Further reading

Sections covered in What a website maintenance plan should actually include: The four things that are non-negotiable, What should be in there but usually is not, What you are probably overpaying for, What it should cost, The clause to refuse, The test
The shape of the argument, in order.

Get new articles by email

One email when something new goes up, roughly twice a month. Plain writing on what software costs and what is worth building. No sequences, no sales calls, and one click to leave.

We use it for the newsletter and nothing else. Unsubscribe any time.

Have something you need built?

Tell us what the problem is. You will get an honest read on whether it is worth building, what it would take, and roughly what it would cost. No pitch deck, no pressure.

Replies within one business day. Mon to Fri, 9am to 5pm MT.

Call Start a project