The build is done, the product is live, and now the agency wants you on a monthly maintenance retainer. The number is not huge, but it is forever, and something about "forever" for a product you thought you now owned makes you hesitate. The hesitation is healthy. A maintenance retainer can be a fair deal or a slow leak, and the deciding factor is what it actually covers and how easily you could leave.
What a maintenance retainer is supposed to buy
Live software is not a finished object. It needs security patches, dependency upgrades, uptime monitoring, bug fixes, and someone to answer the pager when it breaks at 2 a.m. A maintenance retainer is the agency offering to keep doing that so you do not have to hire for it on day one. For an early team with no engineers on staff, that can be genuinely worth paying for. The alternative is that the product rots quietly until a library goes end-of-life or a security hole opens up and nobody was watching.
So the retainer is not inherently a trap. The question is whether you are paying for real, defined work or for a vague promise of availability that mostly protects the agency's revenue.
The difference between coverage and a leak
A fair maintenance retainer is specific. It names what is included: how many hours, what response time for a critical bug, which upgrades are covered, whether small feature tweaks count or are billed separately. It has a clear exit, usually 30 days notice, with no penalty. And it comes with the thing that makes leaving possible at all: full access to your own code, your own infrastructure, and your own accounts.
A leak looks different. A flat monthly fee with no hours attached and no definition of what you get. Response times that are aspirational rather than contractual. A retainer that is really a hostage arrangement because the agency still holds your repository, your hosting, or your domain, so cancelling means losing access to your product. If any of that sounds familiar, the real problem is not the retainer, it is that your agency hosts your product on their servers and the retainer is just the meter running on that dependency.
The test is simple: could you cancel next month and keep operating? If yes, the retainer is a service you are choosing to buy. If no, it is leverage, and the price is whatever they decide it is, because you cannot walk.
How to structure it so it stays fair
Before you sign the maintenance agreement, get four things straight.
- Scope. Written, itemized: patches, upgrades, monitoring, incident response, and a stated number of hours. Anything outside that is a separate quote you approve, not an automatic charge.
- Access. You hold the source code, the cloud accounts, the domain, and the deployment keys. The agency operates with access you grant, not access you depend on. This is non-negotiable and it should have been settled at handoff.
- Exit. A short notice period, no cancellation penalty, and a documented offboarding: where everything lives, how to deploy, who to call. You want to be able to move to an in-house hire or another shop without a crisis.
- Right-sizing. Match the retainer to the actual maintenance load. A stable product with light traffic does not need a large standing commitment. If the agency is pushing a big monthly number for a quiet product, that is worth pushing back on.
It helps to think of the retainer the same way you would think about any ongoing engagement rather than a one-off build. The logic for choosing milestone billing versus an open-ended retainer applies here too: money should track defined work, not just the passage of time.
When to say no
Sometimes the right answer is to decline. If the product is simple and stable, if you are about to make your first engineering hire anyway, or if the retainer only makes sense because the agency controls access you should own, then paying monthly is solving a problem you should fix directly instead. Getting your code and infrastructure into your own hands, then buying maintenance as a defined service or hiring for it, is almost always cheaper over a year than an open-ended fee whose main purpose is to keep you attached.
A maintenance retainer is a tool. Used well, it buys you time before you build an engineering function. Used badly, it turns "we own our product" into "we rent our product from the people who built it." Read the coverage and the exit before you read the price.
FAQ
Do I actually need a maintenance retainer after launch?
Not always. You do need someone responsible for security patches, upgrades, monitoring, and incident response. A retainer is one way to get that; hiring or buying it as a defined service are others. The wrong answer is to have no one watching a live product.
What should a fair retainer include?
Defined hours, a stated response time for critical issues, covered upgrades and patches, monitoring, and a clear line between what is included and what is billed separately. If none of that is written down, you are paying for availability, not work.
How do I keep the retainer from becoming a lock-in?
Own your code, infrastructure, domain, and accounts, and require a short notice period with no penalty. If cancelling would cut off access to your own product, the retainer is leverage, and that access problem needs fixing first.
Is the agency's retainer price reasonable?
Judge it against the real maintenance load, not their template. A stable, low-traffic product needs less than a busy one. If the number feels high for how quiet the product is, book a call and get a second read before you commit to something monthly and open-ended.