How to Price a Maintenance Retainer
Price a maintenance retainer as a fixed monthly fee attached to a defined envelope of work, and anchor the number to the outcome the client is buying rather than to your hours. The outcome is simple to name: a system that keeps working, changes when the business needs it to, and never becomes the client's problem to figure out. When you price against that, the retainer is cheap. When you price against hours, it looks like a cost to trim the moment things are quiet.
The envelope is what makes the number defensible. A retainer is not open-ended support - that is a trap that turns every message from the client into unpaid work. It is a monthly fee that buys a specific, bounded set of things: a block of change requests, a response-time promise, oversight of hosting and dependencies, and a standing relationship so the client is never starting from a cold stranger when something breaks. Define that block, and the price stops being a guess.
Start From the Outcome, Not Your Hours
The fastest way to underprice a retainer is to estimate how many hours of maintenance the system will need and multiply by your rate. It feels rigorous. It is exactly backwards, because with AI-assisted work your hours keep shrinking as you get better, which means hourly maintenance pricing sends your invoice in the wrong direction over time. The better the system runs, the less you earn - that is not a business, that is a slow fade.
Price the outcome instead. Ask what a day of this system being down would cost the client - in lost sales, in staff time, in a stalled process - and set the monthly fee as a small fraction of that. A retainer that costs a fraction of one bad day is an easy yes and stays an easy yes, because the client is not comparing it to your effort. They are comparing it to the risk of the thing they depend on quietly failing with no one on call.
What Goes Inside the Retainer, and What Does Not
A retainer that will not bleed margin has a clear inside and a clear outside. The inside is the bounded envelope of ongoing care. The outside is everything that is really a new project wearing a small-ask costume. Write both down. The line between them is where your margin lives or dies.
A clean envelope: inside the retainer vs a separate quote
| Inside the monthly fee | Outside it - a separate quote |
|---|---|
| A defined block of small change requests per month | A new feature or a whole new section of the system |
| Bug fixes and keeping the system running | A redesign or a rebuild of an existing part |
| Dependency and hosting oversight, security updates | Integrating a new third-party tool from scratch |
| A response-time promise when something breaks | Work that clearly exceeds the monthly change block |
The exclusions list is the load-bearing part, and most people write it too gently or skip it. Be specific. Most scope creep on a retainer happens because the client genuinely believed a new feature was covered and you genuinely did not, so nobody is being unreasonable - the document just failed to draw the line. Put a number on work beyond the envelope, so a bigger ask flips from an awkward favor into a defined add-on the client already expects to pay for.
A Simple Way to Size the Number
You do not need a formula, you need a floor and a ceiling that both come from real things. The floor is your genuine cost to be available and honour the envelope - the standing responsibility, not a guess at hours. The ceiling is a fraction of what the system being broken would cost the client. Your number sits between them, closer to the ceiling the more the business depends on the system.
- Name the outcome in one sentence: what the client actually gets is a working system that keeps working and changes when they need it to.
- Estimate the cost of a bad day: what does it cost this client, in money and time, when the system is down or wrong for a day. That sets your ceiling.
- Define the envelope: how many small changes a month, what response time, what hosting and security oversight. That is what the fee buys.
- Set the monthly fee as a small fraction of the bad-day cost, above your floor to be available. Then write the exclusions list so everything outside the envelope is a separate, numbered add-on.
Sanity check it against a simple test: if the client cancelled the retainer, would the risk they are now carrying feel bigger than the fee they just saved? If yes, the number is right and the retainer sells itself. If the fee feels large next to the risk, either the system does not need a retainer yet or you have priced the envelope too wide for what this client actually uses.
How to Present It So the Client Says Yes
Lead with the outcome, keep the mechanism in the background. The client is not buying change requests and dependency updates - those are how you deliver it. They are buying the fact that the thing their business now runs on will not silently break with no one responsible for it. Every line of the retainer offer should point back to that, or it belongs in an appendix.
Offer it at the moment of maximum trust, which is the handoff. A client who has just been given a working, documented system is the easiest person in the world to offer a retainer to, because they can already see exactly where they will want help next. Present one clear monthly number, the envelope it covers, the exclusions, and the response-time promise, on a single page. One page that a client can read the value of in ten seconds closes better than a long document that makes them feel they are signing something heavy.
Short, practical drops on skills, MCP, agents, prompts, and more. No spam, unsubscribe anytime.
Frequently asked questions
How do I price a maintenance retainer?
Set a fixed monthly fee tied to a defined envelope of work - a block of change requests, a response-time promise, and hosting oversight - and anchor the number to the outcome the client is buying rather than your hours. Size it as a small fraction of what a day of the system being broken would cost the client, above your floor to be available.
How much should a maintenance retainer cost?
There is no flat rule, because it depends on the size of the system and how much the business depends on it. Price it as a small fraction of what a bad day - the system down or wrong - would cost the client, above your genuine cost to be available. If the risk of cancelling feels bigger than the fee saved, the number is right.
Should a maintenance retainer be priced by the hour?
No. Hourly maintenance pricing sends your invoice down as you get faster, which is the wrong direction for a business. Price the outcome - a working system that keeps working - as a fixed monthly fee, so your improving speed stays in your column instead of shrinking what you earn.
What should a maintenance retainer include and exclude?
Include a defined block of small changes, bug fixes, keeping the system running, and hosting and security oversight, plus a response-time promise. Exclude new features, redesigns, rebuilds, and new integrations - those get a separate quote. The specific exclusions list is what stops quick fixes from becoming unpaid work.
When is the best time to offer a maintenance retainer?
At the handoff, right after you deliver a working, documented system. That is the moment of maximum trust, when the client can already see where they will want ongoing help, so a bounded monthly retainer reads as sensible protection rather than an upsell.
Last reviewed by Duncan Rogoff on September 9, 2026
