What a Website Maintenance Retainer Should and Should Not Cover

TL;DR

• A maintenance retainer covers keeping what exists healthy: updates, backups, monitoring, and vendor-caused regression fixes. It does not cover building anything new.
• The single most dangerous phrase in any retainer agreement is "ongoing website support" with no further definition. That phrase funds every scope argument that follows.
• New features, redesigns, content creation, and third-party outages belong outside the retainer scope — and must be named explicitly, not implied.
• A change-order path must exist in writing before you sign. Without it, both sides are improvising when the first out-of-scope request arrives.
• Rollover policy, regression responsibility, and cancellation terms are the three clauses clients most often overlook and most often regret skipping.

---

Why Do Retainers Break Down Before Month Three?

Most maintenance retainers do not collapse because the work is hard. They collapse because the scope was written to close a sale, not to prevent a dispute. Both sides sign on the same understanding — "you will take care of my site" — and then discover they had two different pictures of what that meant.

The client pictures a capable person on call who will handle anything that comes up. The developer pictures security patches, backup checks, and a fixed number of change hours per month. Neither picture is wrong. They are just different products sold under the same name.

The most important clause in a maintenance agreement is scope definition. Vague scope leads to disputes over what is included. That is not a legal observation — it is an operational one. Every ambiguous word in that agreement will eventually get tested by a real request, and the answer will either come from the contract or from whoever negotiates harder that day.

Retainers are not magic. Poorly structured agreements lead to scope creep and billing disputes that compound month after month. The compounding is the problem. One concession in month one becomes the baseline expectation in month two.

What a Retainer Should Cover

The honest version of a maintenance retainer is a recurring operational commitment: keep the thing running, keep it safe, and fix it if something you touched breaks it. Here is what that looks like in practice.

Security and dependency updates. Timely patching helps protect a website against newly discovered vulnerabilities before they can be exploited. Most security vulnerabilities occur within third-party plugins, modules, and extensions. Applying those updates to a staging environment first, then promoting to production, is the baseline. Applying them blind to production is not maintenance — it is a coin flip.

Backups with tested restores. A backup that has never been restored is a belief, not a safety net. The retainer should specify backup frequency, off-site storage, retention window, and how many restores per month are included before billing separately. Restore terms should state whether restores are included within retainer hours, billed separately, or included up to a defined number per month.

Uptime monitoring and SSL hygiene. An expired domain is one of the most common and most painful outages, and almost always avoidable. The contract should clearly name who is responsible. Same logic applies to SSL certificates and health checks. If the retainer does not explicitly own this, assume nobody is watching.

Vendor-caused regression fixes. This is the clause clients most often skip reading. The regression clause is the most frequently absent clause. It should state that if the vendor's change introduces a regression — something that was working breaks — the vendor fixes it at no extra charge, within a defined timeframe. Without it, a botched plugin update can turn into a billed emergency.

Monthly reporting. Reporting — whether and how the client learns what was done — does not need to be elaborate. It should give the sense that someone is actually looking after the site. A monthly summary of updates applied, incidents handled, and hours consumed is sufficient. Silence is not.

What Should Never Be Lumped Into the Retainer?

This is where almost every scope argument originates. Clients do not usually ask for outrageous things. They ask for things that feel small — "just add a contact form to the About page" — and are surprised when that falls outside the plan.

Maintenance is caring for what exists. Development is adding what is new. The contract should name that line and set how development is billed — hourly, a block of hours, or a separate quote. Otherwise either the developer does work they are not paid for, or the client pays a retainer and hears "that is a separate project" at every request.

Maintenance keeps a site healthy; it does not rebuild it. The following typically fall outside a standard plan and should be quoted separately: new features or pages, design overhauls, content creation, and major version migrations or replatforming.

Third-party outages are another common flashpoint. Issues caused by third-party outages — hosting, DNS, CDN, payment processors — are not included unless the provider is also contracted to manage those services. If your payment processor goes down on a Saturday, that is not a maintenance failure. The retainer should say so plainly.

The Table That Belongs in Every Agreement

Request type	In scope?	Why
CMS, plugin, framework dependency updates	Yes	Core maintenance task; keeps vulnerabilities patched
Scheduled off-site backups	Yes	Operational hygiene; frequency and retention must be stated
Uptime and SSL certificate monitoring	Yes	Passive; the retainer owns the watch
Regression fix (vendor-caused)	Yes — at no extra charge	Provider broke it; provider fixes it
Minor text or image content swaps (if included)	Conditional — must be in contract	Define request limit and what "minor" means
New page, new feature, new integration	No — change order required	Development work, not maintenance
Design reskin or layout restructure	No	Scope is net-new, not preservation
Content creation (copy, images, video)	No	Outside engineering scope entirely
Third-party platform outage response	No — unless provider manages that service	Outside provider's control
Emergency security containment	Yes — with written approval if time allows	Active harm reduction overrides normal approval flow

The Three Clauses That Decide Whether a Retainer Is Worth Signing

1. The out-of-scope path. The agreement should define how work beyond scope will be handled, including overage pricing and approval requirements. A change-order process — written request, written quote, written approval before work starts — is not bureaucracy. It is the only thing that prevents an informal Slack message from becoming an unpaid obligation. The provider should obtain client approval before starting out-of-scope work, except for emergency mitigation needed to reduce active harm, such as security containment.

2. Rollover policy. Unused hours at month-end are a genuine question. Many retainers use no rollover, limited rollover with a cap, or rollover that expires after a set time. None of these is wrong; they are just different cash-flow arrangements. What is wrong is not specifying which one applies. Clients who assume rollover and discover otherwise at month three feel cheated, even when the contract was always silent on the point.

3. Cancellation and handover. The agreement should allow cancellation with reasonable notice — 30 days is standard for care plans. More important than the notice period: the handover clause. Who owns the repository access, the hosting credentials, the DNS records? If you cancel, can you take everything with you? If the contract does not answer that, the answer may be "no" by default.

How This Plays Out on a Real Engagement

On the Biz365 AI engagement, the work was a full AI-powered SaaS build — not a maintenance agreement. But it illustrated the same boundary: what keeps existing functionality running versus what adds net-new capability. Those are categorically different efforts, and conflating them in a contract produces the same frustration whether the work is greenfield development or ongoing support.

If you are running a web application rather than a marketing site, the maintenance question gets sharper. A SaaS product with user accounts, payment flows, and a database has more moving parts than a brochure site, and the retainer needs to reflect that. The hospitality SaaS project is a good illustration of how many third-party dependencies a live product actually carries — every one of those dependencies is a potential maintenance surface.

For anything that lives closer to software than to a static website, see the Replit prototype-to-production checklist — it covers the stabilization work that often needs to happen before a sane maintenance retainer makes sense.

The Vague Language That Should Worry You

Avoid agreements that say only "website maintenance services" or "ongoing website support" with no specifics. This language is a setup for scope disputes. These phrases are not placeholders — they are blank checks. Every request that arrives will be evaluated against them, and "support" is a word that can mean almost anything depending on who is reading it.

A common practice is to include a sentence like, "This agreement covers the specific deliverables listed below. Any work not explicitly listed is considered out of scope." That sentence, or something equivalent, should be in every agreement. It is not aggressive. It is honest.

The retainer model looks cheaper on paper than it turns out to be in practice, because the base fee rarely covers what you actually need month to month. Read the fine print — specifically, ask how many edit requests are included and what counts as out of scope. Ask this before you sign, not after the first invoice arrives with line items you did not expect.

If you want to explore what a well-structured retainer looks like in practice, the maintenance retainers service page covers how I structure scope, rollover, and the change-order path for ongoing engagements. Most engagements start around $5K; smaller well-scoped work is considered case-by-case.

---

FAQ

Is a retainer the same thing as a support contract?

They are often used interchangeably, but there is a meaningful difference. A support contract typically defines response times for incidents — something breaks, you call, they fix it. A retainer implies ongoing proactive work: updates applied on a schedule, backups verified, monitoring running continuously. The confusion between the two is itself a source of scope disputes, so ask your provider which model you are actually buying before you sign.

What happens when I want a new feature during an active retainer?

It should go through a change-order process: you describe the request, the provider scopes it, you approve the cost in writing, and then work begins. What should not happen is the feature getting quietly absorbed into the retainer hours because the request came in on Slack and nobody flagged it as out of scope. If your agreement does not describe a change-order path, add one before you sign. Without it, both sides are improvising at exactly the moment when clarity matters most.

Can unused retainer hours roll over to next month?

Only if the contract says they do. Many retainers do not include rollover — the fee covers access to a provider's time and attention for that month, not a bank of hours you can draw down whenever. Some agreements offer capped rollover or rollover that expires after 60 or 90 days. There is no universal standard here, so the only safe move is to ask for the rollover policy in writing before you commit. Assuming rollover when none was promised is one of the most common sources of client frustration on month-three invoices.

Who is responsible when a third-party tool my site depends on goes down?

Generally, the provider is not — unless the contract explicitly includes managing that third-party service. Hosting outages, payment processor downtime, DNS propagation failures caused by a registrar, and CDN incidents are outside the maintenance provider's control. The retainer should name the services the provider actively manages and exclude everything else. If you need coverage for third-party dependencies, that is a separate service-level conversation, not something to assume is bundled.

What should a monthly maintenance report include?

At minimum: a list of updates applied (core, plugins, dependencies), any incidents that occurred and how they were resolved, backup verification status, hours consumed versus hours included, and any items flagged for the client's attention. It does not need to be long. What it needs to do is give you visible evidence that work happened and that someone is actively monitoring the system — not just billing a flat fee and waiting for you to report problems.