Website maintenance plan: how to evaluate the monthly offer before you sign

A maintenance plan is a promise about four kinds of work, and each one should be named with its frequency and its evidence.

The site launches, the invoice is paid, and then the maintenance offer arrives: a monthly plan written so generically that nothing in it can be checked. Updates, backups, support. The owner cannot evaluate it, because the promise was never actually made, and signing it means paying for whatever the words turn out to mean. There is a better way to read the document: a maintenance plan is a promise about four kinds of work, and each one should be named with its frequency and its evidence.

The first kind is updates: the platform and its parts kept current. The evaluation is not whether updates happen, but whether they happen on a schedule, through a staging step, with a way back if something breaks. Updates applied blind to the live site are how sites break on a Tuesday afternoon, with the developer unreachable and the checkout dead. Ask what gets updated, how often, and how a change is tested before it touches the live site.

The second kind is backups: taken on a schedule, stored away from the same server, and restored on purpose at least occasionally. A backup that has never been restored is not a backup; it is a hope with a filename. Ask where the copies live, how far back they reach, and when the last real restore was performed and verified by an actual person.

The third kind is monitoring: uptime and form delivery watched by something that alerts a person, not a dashboard nobody opens. The quiet failures are the expensive ones: the contact form that silently stopped delivering leads for weeks, discovered only when a customer mentions it in passing. Ask what is watched, how the alert travels, and who is on the other end of it at night.

The fourth kind is small edits: whose job they are, what counts as small, and how fast they turn around. This is the least glamorous line and the one that decides whether the relationship feels fair a year in. The unpriced edit is where maintenance relationships die: either the client resents every request or the provider drowns in them. A plan that names the boundary protects both sides.

The honest limits deserve saying plainly: a maintenance plan is not a redesign, not new features, and not marketing. When the quote quietly includes them, the plan is priced as if they will never happen; when it quietly excludes them, the client discovers it mid project. The failure versions repeat across every market: the plan that turned out to be backups only, discovered the week the site was defaced; the update pushed straight to the live site that took the checkout down for a day; the broken form nobody noticed for weeks because nobody was watching the deliveries.

Before signing, ask for the four items in writing, each with its frequency and its evidence: what is updated and on what schedule, where backups live and when one was last restored, what is monitored and who receives the alert at night, and where the boundary of small edits sits. Then ask what is explicitly out of scope, and read that list twice. Where Bloom sits is on the writing side of the promise: our plans name the work, the rhythm, and the evidence, because a promise you cannot check is not a promise. Guidance, not guarantees: maintenance keeps a site healthy, and no plan makes a site immune.