After an app launches, the question of ongoing maintenance is often left vague - a handshake agreement to 'keep it running' without a clear scope of what that means. A software maintenance retainer defines that scope. This article explains what a well-structured retainer should cover, what it should not, and what questions to ask before you sign one.
Why 'maintenance' needs a definition
The word 'maintenance' means different things to different teams. To a developer, it might mean applying dependency updates and fixing regressions. To a founder, it might mean adding the features that did not make it into the launch scope. To a hosting provider, it might mean keeping the server running. When these expectations are not made explicit in writing, the retainer becomes a source of recurring disagreement.
The hidden costs of software development article covers the costs that appear after launch. A maintenance retainer is one of the mechanisms for managing those costs predictably - but only if the scope is clear.
What a maintenance retainer should cover
Bug fixes and regression fixes
A retainer should cover bugs in the code that was delivered - functionality that worked at launch and has since broken, or bugs discovered after go-live that were present in the original build. This is distinct from new feature requests: if a user requests a new capability that was not in the original specification, that is a change request, not a bug fix, and it should be scoped and priced separately.
Dependency and platform updates
Software dependencies release updates on their own schedules, and some of those updates are security patches that are not optional. A retainer should include applying security-relevant dependency updates - for example, updating a library when a vulnerability is publicly disclosed, moving off a runtime version that has reached end-of-life (the Node.js release schedule lists many older major versions as EOL and says production apps should only use Active or Maintenance LTS releases), or applying a configuration change when a platform you depend on makes a breaking change. This is preventive work: neglecting it means the application accumulates technical debt that is more expensive to clear later.
The difference between a security update and a major version upgrade is important. Applying a security patch within the current major version is maintenance. Migrating the entire application from one framework major version to another is a project and should be priced as one. Your retainer should be clear on which category each update falls into.
Hosting and infrastructure monitoring
If your retainer includes hosting, it should cover the infrastructure the application runs on - keeping deployments running, monitoring uptime, responding to outages, and managing any infrastructure costs (Vercel, Supabase, database hosting). What it should not cover without explicit agreement is infrastructure scaling decisions - moving from a free tier to a paid tier, adding CDN capacity, or migrating databases are project-level decisions, not background maintenance tasks.
Monitoring and incident response
A retainer that includes monitoring means someone is watching error rates, uptime, and performance metrics and will respond when something breaks. Confirm what the response time commitment is for different severity levels. A production outage is different from a slow page load: the retainer should define what counts as each and what the response time commitment is.
What a maintenance retainer should not cover
- New features or new functionality - these require a scoped estimate and a separate agreement
- Design changes beyond fixing a broken UI element - new layouts, rebrandings, and UX improvements are project work
- Third-party service issues - if Stripe has an outage or Supabase has a service disruption, that is not the retainer's remit (though a good retainer includes alerting you when it happens)
- Content updates - changing text, swapping images, or updating pricing on a website is content management, not software maintenance
- Rebuilding or refactoring large sections of code - if a component needs to be rebuilt because the original design was flawed, that is typically a project, not a maintenance task
How retainer pricing typically works
Maintenance retainers are usually priced in one of two ways: a fixed monthly fee that covers a defined scope, or a time-based retainer where a set number of hours per month is reserved and anything above that is charged separately. Each model has trade-offs.
A fixed monthly fee gives predictable costs and works well when the application is stable and the maintenance demand is low and consistent. If the application requires significant ongoing change, the fixed fee may be misaligned with actual effort. A time-based retainer gives more flexibility but means costs can vary month to month. The right model depends on how stable your application is and how predictable your maintenance needs are.
Be cautious of very low fixed-fee retainers - below the cost of meaningful engineering time. A retainer that cannot buy a full engineer-day per month is not covering bug fixes, monitoring, and dependency updates: it is covering the appearance of coverage. When something breaks that takes three days to fix, the gap between what was priced and what is needed becomes a point of disagreement.
Questions to ask before signing
- What is explicitly included in the scope - bug fixes, dependency updates, hosting, monitoring, incident response?
- What is explicitly excluded - new features, major version upgrades, content changes?
- What are the response time commitments for different severity levels?
- What happens if the monthly effort exceeds what the retainer covers - is there a cap, an overage rate, or a conversation?
- Who is the named contact for your account, and what is their availability?
- What is the notice period to end the retainer, and what handover is included?
- How is the retainer reviewed - is there a regular check-in to assess whether the scope still matches the need?
What good retainer documentation looks like
A well-written retainer agreement is a short document - two to four pages - that covers scope, exclusions, response times, pricing, and termination. It is not a full statement of work, but it should be specific enough that a new person joining either side could read it and understand what is and is not covered. Verbal agreements about what is 'included' do not survive team changes.
If your current arrangement is informal - a developer you call when something breaks, at a rate you agreed verbally - consider formalising it. The conversation about scope is easier before a three-day outage than during one.
Our support and hosting service covers the areas described above - bug fixes, dependency updates, monitoring, and infrastructure management - with a clear scope document. See the pricing page for current plan details, or ask us about a retainer if you want to talk through what your specific application needs.
Common questions
What should a software maintenance retainer include?
A retainer should cover bug and regression fixes, security-relevant dependency and platform updates, hosting and infrastructure monitoring, and monitoring with incident response. It should define response times for different severity levels, such as an outage versus a slow page.
What is not covered by a maintenance retainer?
New features, design changes beyond fixing a broken element, third-party service outages, content updates, and large rebuilds or refactors are normally outside a retainer. They need a scoped estimate and a separate agreement.
What should I ask before signing a maintenance retainer?
Ask what is included and excluded, the response times by severity, what happens if monthly effort exceeds the retainer, who your named contact is, and the notice period and handover on exit. Zovintra offers a support and hosting service with a clear scope document.
Sources
- Node.js Releases - Node.js project, accessed 19 Oct 2026
