Home · About · Services · Industries · Projects · Products · Process · Blog · FAQ · Contact
Application support retainer: what it covers and how it works What a monthly application support retainer should include, how hours and severity levels work, what sits outside it, and what to agree before you sign.
You have a live application that people depend on. The build project has closed, the developer who knew it best has moved on, and small problems keep arriving: a failed login here, a slow report there, a dependency warning nobody has read. You want someone accountable for it every month without hiring a full-time engineer. That is what an application support retainer is for.
An application support retainer is a monthly agreement in which a team keeps a live application working. It normally covers bug fixes, security patches, dependency and framework updates, monitoring, incident response and a set number of hours for small changes. Coverage hours, response times by severity and what counts as out of scope are written into the agreement.
We run maintenance retainers for web applications and campus systems. This guide explains what a sensible retainer includes, how the hours and response times usually work, and what to settle before you sign.
What a retainer usually covers The exact list depends on the application, but most good retainers cover the same six areas. If one of these is missing, ask who is doing it instead.
Corrective fixes: bugs reported by users or caught by monitoring are logged, reproduced on staging, fixed and released with a note of what changed. Security patching: advisories for your dependencies are tracked with tools such as Dependabot, npm audit or pip-audit, and fixes are applied on a regular cycle, sooner for serious ones. Framework and runtime upgrades: Angular, React, Django, Node.js and Python all have support windows. The retainer should keep you inside them, usually moving one major version at a time. Monitoring: error tracking, uptime checks and log review, so the support team sees failures before your users report them. Incident response: when something breaks, a named person investigates, restores service, and writes a short account of the cause. Small enhancements: an extra field, a new export, a changed email template. These come out of an agreed bank of hours rather than becoming separate projects. Depending on how the application is hosted, a retainer may also cover the server or cloud account underneath it: certificates, backups, disk space and operating system updates. Some teams prefer to keep application support and infrastructure support in separate agreements. Either works, as long as the boundary is written down and nobody assumes the other side is watching the backups.
How the hours work Most retainers are priced around a monthly block of engineering time plus a fixed amount of routine work. The routine part covers the things that happen every month regardless: reviewing advisories, checking monitoring, confirming backups ran. The block of hours covers reactive fixes and small changes.
The detail that matters most is what happens at the edges. Settle these points before you sign:
Unused hours: do they expire at month end, roll over for a limited period, or carry forward without limit? A short rollover window, such as one month, is common and fair to both sides. Overruns: if a busy month needs more time, is extra work billed at an agreed rate, or does it need your approval first? We prefer approval for anything above a small threshold. Minimum units: is a five-minute fix logged as five minutes, fifteen minutes or an hour? Small differences add up across a year. Who decides priority: when the hours are limited, you should choose which changes go first, not the support team. Bugs in work the support team did: a fix for a defect introduced by the support team's own change should not usually come out of your hours. Agree this in writing. If an application is changing quickly and you need several days of development every week, a retainer is the wrong shape. A dedicated team or a fixed-scope project for the larger change usually works better, with the retainer covering the steady state afterwards.
Severity levels, response and resolution Response time and resolution time are different promises, and confusing them causes most retainer disputes. Response means a person has acknowledged the issue and started work. Resolution means the problem is fixed or a workaround is in place. Nobody can honestly promise resolution times for unknown bugs, so a retainer should commit to response times and to a process for resolution.
A simple severity scheme that most organisations can apply without debate looks like this:
Critical: the application is down, data is at risk, or a security issue is being exploited. Work starts within the agreed critical response time and continues until service is restored. High: a core workflow is broken for many users and there is no workaround, such as fee payment, admissions or appointment booking failing. Medium: something is wrong but there is a workaround, or only a few users are affected. Low: cosmetic problems, minor annoyances and questions, handled in the normal queue. Each level gets a response time, and each response time is tied to coverage hours. 'Within one hour' during business hours on weekdays is a very different commitment from 'within one hour at any time'. Coverage hours and response times are agreed in the retainer, so make sure they reflect your busiest periods. A college system during admissions or a clinic system on a Monday morning needs more than an average week suggests.
Also agree how issues are reported. One channel, usually a ticketing tool or a shared email address, beats messages scattered across chat apps and personal phones. It gives you a record, and it makes response times measurable.
What a retainer should not cover A retainer is for keeping an application healthy and making small changes. It goes wrong when it quietly becomes a feature budget. When new modules are squeezed into maintenance hours, the preventive work is what gets dropped, and that is the work that keeps future changes cheap.
New modules or major features, which deserve their own scope, estimate and testing plan. Large rewrites or a move to a different framework. Problems caused by third-party services outside your control, beyond investigating and reporting them to the provider. Training large groups of end users, unless that is explicitly included. Work on systems that were never handed over, such as a server the support team has no access to. Out of scope does not mean refused. It means the work is estimated and approved separately, so the retainer hours stay available for what they are meant for.
The first month: onboarding and takeover If the support team did not build the application, the first few weeks are about understanding it before changing it. Skipping this step is how retainers start badly. On a takeover we work through a fixed sequence:
Get access to the repository, hosting, domains, monitoring and third-party accounts, in your organisation's name rather than an individual's. Get a clean build running locally and on a staging environment, from the code in the repository. Record framework, runtime and database versions, and when each leaves support. Check that backups exist, are stored off the main server, and actually restore. Write a short state-of-the-code report: risks, missing tests, abandoned libraries and anything urgent. Fix the urgent items first, usually critical security patches and gaps in monitoring. When an application is badly neglected, this work is better done as a separate fixed-scope stabilisation project, with the retainer starting once the basics are safe. Otherwise the first few months of hours disappear into catching up.
Reporting and a clean exit A retainer should leave a trail you can read. A short monthly report is enough: issues raised and resolved, response times against the agreement, updates applied, hours used, and a list of upcoming risks such as a framework version leaving support or a database growing faster than expected. That last list lets you budget for bigger work a term or a year ahead.
Also think about the end before you start. Your code, configuration and documentation should live in your own accounts, and the agreement should state a notice period and a handover process. Because ownership stays with you, a good support team makes it easy to bring the work in-house or move to another provider. If a retainer would be hard to leave, that is a reason to look harder before signing.
Checklist before you sign The scope lists bug fixes, security patching, upgrades, monitoring, incident response and small changes, or says who covers each instead. Coverage hours and response times by severity are written down and match your busy periods. Response and resolution are defined separately. The rules for unused hours, overruns and minimum billing units are clear. Out-of-scope work has a simple estimate-and-approve process. There is a single channel for reporting issues. Repositories, hosting and domains are in your organisation's accounts. You will receive a monthly report that includes upcoming risks. The notice period and handover process are agreed. If you cannot answer most of these for your current arrangement, it is worth a conversation with whoever supports your application now. Most gaps are easy to close once they are written down.
Infigini IT Services · 11 Kanwali Road, Dehradun 248001, India · info@infigini.com · +91 95684 87789