What a maintenance retainer should and should not cover
A retainer without limits becomes unlimited development, and a retainer that ignores a bad audit becomes a surprise invoice. What to put in, what to keep out, and what to price after the audit.
- Routine upkeep is in. New features are out, handled as change requests.
- Put limits in writing: what is covered, what is capped, what is excluded.
- If an audit finds serious problems, remediation comes before routine upkeep.
- Price the retainer after the audit, not before.
Quick answer
A maintenance retainer should cover routine upkeep inside written limits: monitoring, patches, small fixes, deploys and a monthly note. New features should be change requests. If an audit finds serious problems, fixing them is a separate phase, written into the scope before routine upkeep begins.
The short answer
A good maintenance retainer says what it covers, what it caps and what it refuses. The refusals matter most, because that is where disputes start. And it is written after the audit, not before.
Our view, stated plainly: an unlimited retainer is a bad deal for both sides. The buyer thinks they bought a development team on call. The vendor thinks they sold a few hours of upkeep. Both are right about what they meant and wrong about what the other heard.
Why buyers ask this
You have software that works, and you want someone to keep it working. The risk is a retainer that sounds cheap and turns into unlimited development, or one that hides a large repair bill inside the word “maintenance”. Operations leads feel this first, because they are the ones filing the requests and waiting.
What maintenance is, and what it isn’t
| Maintenance | Development | |
|---|---|---|
| Purpose | Keep what exists running safely | Change or add behaviour |
| Examples | Patches, dependency updates, monitoring, small bug fixes, routine deploys | A new feature, a redesign, a new integration |
| Pricing logic | A recurring scope with a cap | An estimate per piece of work |
| Who decides | The vendor, within the scope | The buyer, by approving a change request |
If a request changes what the system does, it is development. If it keeps the system doing what it does, it is maintenance. When you can’t tell, treat it as a change request and write the estimate down.
What belongs in
- Monitoring and incident response. How you find out something is broken, who is told, and how fast a response is promised. Write the response time down as a target, not a guarantee, unless you are paying for a guarantee.
- Security patches and dependency updates. Security patches first. Routine upgrades in small batches, with a way to verify each.
- Small bug fixes up to an agreed size.
- Routine deploys and a documented rollback, so a release is a repeatable step.
- Access reviews. Who has production access, and do they still need it?
- A monthly report. What was done, what was found, what is next.
- A quarterly health check. Re-score the system against a fixed list so you can see whether it is getting better or worse.
What stays out
- New features. Each is a change request with an estimate and a date.
- A redesign. Its own project, its own plan.
- Unlimited fixes. Cap the work, and write what happens when the cap is reached.
- Work on systems nobody has audited. See below.
- Third-party costs. Hosting, messaging and payment fees belong to the business, not the retainer.
Remediation comes before upkeep
We scoped a maintenance retainer, with explicit limits, for a marketplace client after we audited their system. The audit’s conclusion was that maintenance there had to include a remediation phase before it could become routine upkeep, and the scope says so in writing.
The risk of pricing before an audit is that one of two things happens. Either the vendor absorbs an unplanned repair, which ends in cut corners, or the client gets a surprise invoice, which ends in distrust. Neither is a good start.
Price the retainer after the audit if you can. If you can’t audit first, write the remediation phase in as a separate, scoped line, and agree that routine upkeep begins when it ends.
Match the process to the risk
A retainer works best when it says how much care each kind of change gets. Ours sorts changes into four classes:
| Class | Typical change | Care it needs |
|---|---|---|
| Low | Copy, a small styling fix | Self-review |
| Medium | A change to an existing endpoint, an authentication screen, a new integration | Peer and security review |
| High | Payments, authentication, authorisation, database changes, production config | Peer, architecture and security review, rollback plan, explicit approval |
| Critical | Production credentials, payment settlement, data migration | Written proposal, named approval, a tested rollback, off-peak window |
When in doubt, classify up. Writing the classes into the retainer means the client knows why a payment change takes longer than a copy fix, and doesn’t read the delay as the vendor dragging their feet.
A rhythm you can hold the vendor to
- Weekly: triage new technical debt, review incidents and confirm each action has an owner.
- Monthly: review the debt register and who has production access, and send the report.
- Quarterly: re-score the health check, review past decisions, run a dependency upgrade pass and repeat the security review.
Boring is the point. A retainer that produces a regular, dated paper trail is worth more than one that promises heroics.
Pricing models, and which we’d choose
| Model | Works when | Watch out for |
|---|---|---|
| A fixed monthly scope | The system is stable and the work is predictable | The cap. Write it down |
| An hours bank | Demand varies month to month | Unused hours expiring, and what counts as an hour |
| On-call only | The system rarely needs work | Slow response if the vendor has moved on |
| Remediation phase, then fixed scope | You have just had an audit | Agreeing what “done” means for the first phase |
We would pick the last one after any audit that found serious problems, and a fixed scope otherwise. We don’t publish fees from client work.
Write the limits down
| Item | Write down |
|---|---|
| Covered work | The list, in plain words |
| Cap | Hours or kinds of work, and what happens beyond it |
| Excluded | New features, redesign, remediation outside the agreed phase |
| Response targets | For incidents, by severity |
| Change requests | Who approves, how they are estimated |
| Access | Who holds production access and how it’s reviewed |
| Reporting | What you get each month and each quarter |
| Handover | What you get if the engagement ends |
| Ownership | Who owns the code, the data and the accounts |
Red flags in a retainer proposal
- No exclusions, or “and any other issues that arise”.
- A price before anyone has looked at the system.
- No mention of what happens past the cap.
- No report, no cadence, no record of what was done.
- The vendor holds the only copy of the credentials.
- No exit clause or handover.
We scoped this retainer; we don’t claim it has run for a long time or produced a measured result. We never publish fees or terms from client work. And if your software is a small, stable tool that changes once a year, an on-call arrangement may be all you need.
Next: taking over software another vendor built and the tech handover checklist.
The marketplace facts come from our own audit, scope and operating-procedure documents, tracked in our claim ledger. The client is under an NDA, so no client, fee or term appears. The checklist, risk classes, cadence and pricing views are our own practice and proof grade 4, not an industry standard.
More by GarunaCDX
Let's talk about your build.
Tell us what you are building. A founding engineer replies within one working day with how we would approach it.
