DEV Community

Cover image for What a Maintenance Retainer Should Actually Cover
Sonal Jain
Sonal Jain

Posted on

What a Maintenance Retainer Should Actually Cover

A maintenance retainer should cover four things in writing: keeping the system running, keeping it patched, a fixed pool of small changes, and a named person accountable when it breaks. Most retainers I have inherited covered the first one loosely and left the rest to goodwill, and the arguments started in month three when a "small change" turned out to be a week and a security patch turned out to be nobody's job.

What does "keeping it running" actually mean?

More than uptime. It means monitoring that a person actually reads, backups restored on a schedule, certificate renewals, hosting bills reviewed monthly, disk and queue alerts wired to a human, and a log of every deploy. Those tasks belong in a written checklist with a cadence beside each one.

A backup that has never been restored is a hope with a file name. I ask every team taking on a retainer to run one restore test in the first month, and I have lost count of the times that test found a backup job which had been silently failing for weeks.

Vague retainers get resented from both sides: the client feels they are paying for nothing, and the team feels they are doing invisible work. The checklist settles both, because it shows what "running" costs and what it includes.

Who pays for the updates nobody planned?

The retainer, if it is written properly. Framework upgrades, library patches, operating system updates and third-party endpoints being deprecated are not features and not optional. A system left alone for a year has quietly become an older system with known holes in it.

AI features add a second list. Model versions get retired, prompts tuned over months start behaving differently, and token costs creep as usage grows. That upkeep is part of the real bill of automation, so every AI integration we hand over now leaves with a line in the retainer covering it, and a monthly review of the AI spend next to the hosting spend. A client who discovers that drift from their own finance team is a client who thinks the feature is broken.

How big is the small-change pool, and what counts as small?

A monthly block of hours, with unused hours rolling over one month and no further. Small means a change one person can finish and test in under a day, with no new screens and no data model changes. Anything larger is a change request with its own estimate.

Counts as small, inside the pool Counts as a change request
Reword an invoice email template A new approval step with its own screen
Add a column to an existing report A report that needs a new field in the data model
Fix a call to a third-party endpoint that moved Swapping the third-party provider entirely
Apply a security patch and redeploy Migrating to a new framework major version

The rollover rule stops the client paying for air and stops the team carrying a growing debt. The definition matters more than the number of hours. Most retainer disputes I have mediated were about whether something counted as maintenance, and every one of them would have been settled by a sentence written before the contract was signed.

What does accountable actually look like?

A named person, response times by severity, and a monthly report. Severity one, meaning the system is down or data is at risk, gets a human within an agreed window around the clock. Severity two, a broken feature with a workaround, gets a response within a working day. Everything else joins the queue.

The named person changes as people change, but there is always one, and the client always knows who. The monthly report is thirty minutes and one page: what broke, what we patched, hours used from the pool, the bills, and anything we recommend before it becomes urgent. It is the least glamorous meeting on my calendar and the one that most reliably turns a maintenance client into a client for the next build.

The first month of any retainer I take on runs in the same order:

  1. Run one restore test from a real backup, before anything else is agreed.
  2. Write the running checklist, with a cadence beside every task.
  3. Put the small-change definition into the contract, in one sentence.
  4. Name the accountable person and the severity response windows.
  5. Book the monthly report meeting for the whole year, in advance.

At Shanti Infosoft I would rather lose a retainer negotiation over the pool definition than win one that both sides misunderstand. The misunderstanding always costs more than the hours. If yours is up for renewal and you want those four sections read by someone who has argued about all of them, my calendar is here.

What does your current maintenance agreement say happens when a library you depend on stops being supported?

Sonal Jain is delivery lead at Shanti Infosoft, a CMMI Level 5 software firm that has supported systems for 700+ companies.

Top comments (0)