What a software maintenance retainer actually covers (and what it does not)

Almost every unhappy maintenance retainer fails the same way. The client believes they bought "someone looking after the system." The vendor believes they sold a fixed number of hours. Nobody wrote down which one it was, and four months later there is an argument about whether a new report is a fix or a feature.

The fix is boring: decide where the line is, in writing, before money changes hands. Here is where we put it and why.

What maintenance is

Maintenance is the work that keeps a system in the condition it is already in. Left undone, the system gets worse without anyone touching it — which is the part people underestimate. Software decays while you ignore it.

Concretely:

• Dependency and security patching. Libraries publish advisories continuously. Applying them is unglamorous and non-negotiable.
• Uptime and performance monitoring. Someone should know the site is down before the client does. This is the single clearest test of whether you have maintenance or just an hourly arrangement.
• Backups, verified. An unverified backup is a belief, not a backup. Restoring one on a schedule is the only thing that makes it real.
• Bug fixes. Behaviour that was supposed to work and stopped.
• Small changes within the existing shape of the system. A new column on an existing report. A copy change. A field on a form.
• Compatibility work. Runtime upgrades, deprecated APIs, browser changes, certificate renewals.

What it is not

Everything below is real work worth paying for. None of it is maintenance, and quietly absorbing it is how a retainer stops being profitable and then stops being available.

• New features. A capability the system did not previously have.
• Redesigns. New visual direction, new information architecture.
• Migrations. Moving hosts, changing databases, replacing a third-party service.
• New integrations. Connecting a system you just bought.
• Data work at volume. One-off imports, cleanups, backfills.

The distinction is not effort. A "small" new feature can take longer than a month of patching. The distinction is whether the work returns the system to its intended state or extends what the system does.

The test we use

When something arrives and it is genuinely ambiguous, one question resolves most of it:

If we do nothing, does the system get worse?

If yes, it is maintenance — it comes out of the plan. If no, it is an enhancement — it gets quoted, and it does not start until it is approved. This is not a way of saying no. It is a way of making sure a request that will take twenty hours does not silently consume a month's allowance that was meant to keep the system safe.

Hours are the wrong thing to shop on

Most retainers are sold as an hour count, and hours are the least interesting part of the arrangement. Consider what an included-hours number does not tell you:

• Response time. Ten hours a month is worthless if nobody replies for four days.
• Whether monitoring is included. If it is not, you are paying for reactive work and finding out about outages from customers.
• What happens beyond the allowance. Quoted in advance, or billed as a surprise?
• Whether unused hours are wasted. A quiet month should not be money burned.
• Who does the work. A senior engineer who knows your system, or whoever is free.

We publish our pricing with the hours attached because comparison is fair. But the response time and the monitoring are what you are actually buying.

The invoicing problem this solves

There is a second reason retainers exist, and it has nothing to do with scope.

Hourly maintenance produces unpredictable invoices. Work accumulates quietly, then arrives as a bill nobody planned for. We have had stretches run four months and land on a client as a single large invoice — bad for their budgeting, and bad for us, because months of work sat unbilled.

A flat monthly fee fixes both sides of that. The client knows the number. The vendor gets paid on a cadence. Neither party is surprised, which removes the most common reason maintenance arrangements quietly lapse.

Questions to ask before signing

1. What is your response time, and is it a target or a commitment?
2. Is monitoring included, and will you tell me about an outage before I notice it?
3. What specifically is excluded?
4. What happens when I go over the included hours?
5. Do unused hours roll over?
6. Who is actually doing the work, and will it be the same person in six months?
7. What do I get in writing each month?

If a vendor cannot answer four and three quickly, that is the conversation you will be having in month five instead.