Guide · Upgrades and maintenance
What a maintenance retainer should include, and what drives its cost
By MervenorPublished Last reviewed 3 min read
A good maintenance retainer keeps an application current and safe, ships small improvements, and says in writing how fast someone responds and what is not included. The monthly fee is driven by the hours, the response commitments and how complex and fragile the system is. Compare retainers on those terms, not on an hourly rate.
What it should include
- [ ] Framework, runtime and dependency updates on a stated schedule.
- [ ] Security patches applied within a stated window after release.
- [ ] Monitoring of uptime and errors, with alerts during stated hours.
- [ ] Backups checked, and a restore tested at least once a quarter.
- [ ] Incident response with written response times by severity.
- [ ] Small improvements from a prioritised list that you control.
- [ ] A written monthly report: what shipped, what is next, what worries the engineer.
- [ ] Documentation kept current as the system changes.
- [ ] Work done in your repositories and accounts, with a clean handover clause.
Response commitments
Define severity levels in plain words (for example, "the site is down or data is at risk", "a key feature is broken", "everything else"), and commit to a response time for each. Response means a qualified person is working on it; resolution times depend on the cause and are rarely promised honestly. State the working hours the commitments apply to. A provider that promises round-the-clock cover should be able to show who is awake at 3 a.m.
What it should exclude, or say clearly
- New features larger than the monthly hours allow (quoted separately).
- Outages of third-party services you depend on.
- Content and copy changes, unless they are part of the agreement.
- Hosting and licence costs, which usually stay in your name.
- Emergency work outside the stated hours, unless agreed and priced.
Hours: unused time and overruns
Agree in advance what happens to unused hours (lost, or carried over for a month), what happens when a month runs over (paused, or billed at an agreed rate), and how you see the hours used. Surprises here damage more retainers than technical problems do.
What drives the monthly fee
- The number of hours each month.
- The response commitments and the hours they cover.
- The size of the system: services, environments, integrations.
- How healthy the code is. A fragile application costs more to keep running, which is why a stabilisation sprint usually comes first.
- Compliance needs: audits, security questionnaires, evidence of patching.
- How often you release.
Red flags
- No written scope, or "unlimited small changes".
- No monthly report, or a report with no detail.
- Accounts, repositories or domains held in the provider's name.
- Long lock-in periods with no exit or handover clause.
- Promises of round-the-clock cover with no named on-call arrangement.
Questions to ask before signing
- Who will work on our application, and do they already know the codebase?
- What are the response times, and during which hours?
- How are priorities set each month, and who decides?
- What happens to unused hours, and to overruns?
- How do we leave, and what do we receive when we do?
Servata, the care retainer, is a monthly block of senior engineering time with written response commitments. It follows a Firmora sprint, so it starts from a stable application.