Software Maintenance Retainer: What It Should Include and What It Costs (2026)

A software maintenance retainer is a monthly agreement that keeps a development team on your software after launch: fixing what breaks, keeping it patched, and building the next small things your users ask for. Almost every custom application needs one, or something like it, because software that nobody touches does not stay the same. It gets older while everything around it moves. This guide explains what a retainer should include, the four ways firms usually price one, what drives the monthly number, the fine print that decides whether it protects you, and seven checks to run before you sign. It is written by Paul Byrne, President of Razoyo, a software engineering firm that sells retainers, so read our part with that in mind. We also say when you do not need one.

What is a software maintenance retainer?

It is a standing monthly arrangement for ongoing work on software you already have. Instead of scoping and signing a new project every time something needs doing, you agree a monthly amount and a way of deciding what the team works on. The work usually falls into four buckets:

• Keeping it running. Monitoring, responding when something fails, and fixing bugs.
• Keeping it safe. Security patches, dependency upgrades and moving off language and framework versions that are reaching end of life.
• Keeping it current. Small features and changes your users or your team ask for.
• Keeping it understood. Documentation, a project board and someone who knows the system well enough to plan the next release.

A retainer is not the same as a warranty. A warranty covers defects in what was delivered, for a fixed period. A retainer covers the life of the software after that, including work nobody could have predicted at launch.

Why does software need maintenance if nothing is broken?

Because the software around yours keeps changing, and some of those changes are deadlines. Every application depends on a language runtime, a framework and dozens of third-party packages, and each of them has a support window.

Two examples with dates on them. PHP says each release branch “is fully supported for two years from its initial stable release,” then gets security fixes only for two more years, after which “the branch reaches its end of life and is no longer supported” (PHP supported versions). Its own table shows PHP 8.2’s security support ending on 31 December 2026. Node.js puts the rule plainly: “Production applications should only use Active LTS or Maintenance LTS releases” (Node.js releases). An application that is not moved forward eventually runs on versions that no longer get fixes.

The second reason is attacks. CISA keeps a catalog of vulnerabilities that are being exploited right now and says “organizations should use the KEV catalog as an input to their vulnerability management prioritization framework” (CISA Known Exploited Vulnerabilities catalog). Someone has to watch for the packages your software uses and patch them.

NIST frames all of this as an ordinary business cost rather than an emergency. Its patch management guide frames patching as “a critical component of preventive maintenance for computing technologies” and calls it “a cost of doing business” (NIST SP 800-40 Rev. 4). That is the honest way to think about a retainer: preventive maintenance, budgeted like rent, not a sign that something went wrong.

What should a software maintenance retainer include?

At minimum, these seven things. If a proposal leaves one out, ask where it went.

1. Bug fixes, with a clear statement of how they are reported, prioritized and charged.
2. Security and dependency updates, including planned upgrades before a runtime or framework reaches end of life.
3. Monitoring and an emergency path, so you are told when something fails, and you know what it costs to get help at 2am.
4. Small feature work, estimated before it starts.
5. A review step on every change, ideally a second developer reading the code before it merges, and a staging environment where you see the change before your users do.
6. Visibility, meaning access to the board where the work is planned and tracked, not just a status email.
7. Exit terms, a notice period and a handover list, so the retainer protects you rather than holding you.

Hosting is often bundled in. That is fine, as long as the hosting account is in your company’s name. More on that below.

How do firms usually price a retainer?

There are four common models. None is wrong. Each fails in its own way.

The model matters less than two questions you can ask about any of them: who decides what gets worked on, and what happens when the money for the month runs out? A good retainer answers both before any work starts. A bad one answers them on the invoice.

What does a software maintenance retainer cost?

It depends on the software more than on the firm, so be wary of anyone who quotes a monthly number before they have looked at your code. The things that drive the number are knowable:

• How old the stack is. Software running on versions near end of life needs upgrade work before routine maintenance is cheap.
• How much it is used. More users means more edge cases, more support and more cost when it fails.
• How many outside services it connects to. Every payment provider, API and integration changes on its own schedule.
• How much new work you want. Pure upkeep is the smaller part of most retainers. Feature requests are usually the larger part.
• Whether the code has tests and a repeatable deploy. Without them, every change takes longer and carries more risk, so it costs more.

For a real reference point, ours start from $1,500 a month, and our pricing page lists everything else we charge. That is a starting point, not a quote. A larger scope costs more, and we say so before you commit. If you need a defined block of work rather than a monthly relationship, dev bursts are $1,200 per developer per day or $4,500 a week.

If the software was built by someone else, expect the first month or two to cost more than the months after. The new team has to read the code, get the deploy path working and catch up on skipped updates. What to do when a launched app keeps going down covers the case where that catch-up is urgent.

How do you stop a retainer from becoming a blank check?

Make three things conditions of the agreement. Most retainer disputes trace back to one of them being missing.

• Every piece of work is estimated and approved before it starts. Not a monthly report of what was done, but a yes or no from you before anyone begins. At Razoyo a business analyst puts a level of effort and a budget on each item and gets your confirmation first. No approval, no work.
• The monthly number stops itself. The team works to the agreed amount and tells you when it is reached. Going over needs your say-so, not a surprise on the invoice.
• You can see the queue. Access to the board means you can reorder the work, question an estimate or stop a task, instead of finding out what the hours bought at the end of the month.

With those three in place, any of the four pricing models above can work. Without them, even a cheap retainer is an open-ended commitment.

What should the contract say about leaving?

That you can leave, how fast, and with what. A retainer that is hard to exit is not maintenance. It is lock-in.

• A notice period measured in weeks, not a long minimum term. Ours is 30 days to stop and 15 to change the budget.
• Ownership of the code on payment of fees. Once fees are paid you own the code we write for you, and our you own the code page lists what that covers and what we keep.
• Accounts in your company’s name. Repository, hosting, domain and every third-party service. When a client leaves us, the handover includes those accounts “with credentials rotated so we no longer hold the keys.”
• A handover a stranger could use. Documentation, the deploy path and the board. The test we hold ourselves to is the one to put to any firm: could another competent team pick this up on Monday?

If you already depend on a team that fails these, the firms that take over existing codebases are compared in one place, us included.

Razoyo’s Seven-Line Retainer Check

Run these seven checks on any retainer proposal before you sign, ours included. They come from the terms we publish on our pricing page, our process page and our ownership page. Each has a pass and a fail.

1. Who approves each piece of work? Pass: you do, against a written estimate, before it starts. Fail: the team decides and reports afterward.
2. What happens when the monthly budget runs out? Pass: work stops and you are asked. Fail: overage is billed automatically.
3. Can you see the board? Pass: you have access to the same board the team works from. Fail: you get a summary email.
4. Who reviews each change, and where do you see it first? Pass: a second developer before it merges, then a staging environment you can check. Fail: changes go straight to production.
5. Is testing included or billed on top? Pass: included and named, for example code, acceptance and regression testing. Fail: “we test” with no detail, or testing as a separate line.
6. What does an emergency cost? Pass: a published path and a published rate, and you decide when to use it. Fail: “call us,” with the price decided afterward.
7. How do you leave, and with what? Pass: weeks of notice, code owned on payment of fees, accounts in your name with credentials rotated. Fail: a long minimum term, or no handover terms.

What does Razoyo’s retainer include?

Ongoing support starts from $1,500 a month, as a flat monthly rate with no setup fees. Here is what our process page and pricing page say it includes:

• Unlimited bug fixes through our automated systems, plus feature work, support, hosting and continuous improvement.
• The same senior team that already knows the product. No handoff, and no restarting the learning curve.
• Every pull request reviewed by a lead developer before it merges, and a staging site where you approve every change before it reaches production.
• Three layers of testing on every change, code, acceptance and regression, not billed separately.
• AI agents around the clock for triage and routine tasks, with senior oversight.
• Bi-weekly check-ins with a project manager, and requirements work for the next release included, so the next build starts ready.
• An emergency line with its own rate. You decide when to use it.
• Month to month. Thirty days’ notice to stop, fifteen to change the budget.

We say “the same team” because it is the part that is hardest to buy. We are still the engineering team behind Spider, the hotel business intelligence platform now part of Lighthouse, used by more than 10,000 people a day. And as our about page puts it, “Many of our clients have been with us for more than a decade.” A retainer is mostly paying for people who already understand your system. That only works if they stay.

When do you not need a retainer?

More often than firms that sell retainers like to admit. You probably do not need one if:

• The software is simple and rarely changes. A small internal tool on a supported stack may need a few days of work a year. Book that as a burst when it is due, and put a reminder in the calendar for each end-of-life date.
• You have your own developer. A retainer can still help as backup or for review, but it should be smaller and say so.
• The job is genuinely small and well defined. Our pricing page says it directly: “If your project is genuinely simple and well-defined already, a freelancer may be the right call.” Our freelancer or engineering firm comparison covers when that is true.

And if you are not sure the software is worth maintaining at all, settle that first. Rewrite or refactor an inherited codebase explains how to decide.

Key takeaways

• Software ages even when nothing breaks. Runtimes, frameworks and packages have end-of-life dates, and some vulnerabilities are being exploited now.
• A retainer should cover seven things: bug fixes, security updates, monitoring with an emergency path, small features, review and staging, visibility and exit terms.
• The pricing model matters less than control. Approve every item before it starts, make the budget stop itself, and see the board.
• Ask what drives the number. Stack age, usage, integrations, feature demand and test coverage set the cost, not the firm’s logo.
• Make leaving easy. Weeks of notice, code you own on payment of fees, and accounts in your name.

Key terms glossary

• Software maintenance retainer. A monthly agreement that keeps a development team working on existing software: fixes, updates, monitoring and small changes.
• End of life. The date after which a language version, framework or product stops receiving fixes, including security fixes.
• Dependency. A third-party package or library your software relies on, which has its own updates and vulnerabilities.
• Staging environment. A private copy of the application where changes are checked before they reach real users.
• Regression testing. Re-running tests after a change to confirm that what used to work still works.
• Dev burst. A short, fixed-scope block of development work bought outside a retainer, billed by the day or week.

FAQ

What is a software maintenance retainer? It is a monthly agreement that keeps a development team on your software after launch. It usually covers bug fixes, security and dependency updates, monitoring with an emergency path, and small changes, with an agreed way of deciding what gets worked on each month.

What should a software maintenance retainer include? Bug fixes, security and dependency updates, monitoring and an emergency path, small feature work estimated before it starts, a second developer reviewing each change plus a staging environment, access to the project board, and exit terms with a notice period and a handover list.

How much does a software maintenance retainer cost? It depends on the software: how old the stack is, how many people use it, how many outside services it connects to, how much new work you want, and whether it has tests and a repeatable deploy. Razoyo’s ongoing support starts from $1,500 a month, and a larger scope costs more.

Do I need a retainer if my software is not broken? Usually, yes, because the software around yours keeps changing. Language and framework versions reach end of life, and vulnerabilities in common packages are exploited in the wild. If your software is simple and rarely changes, booking a few days of work when updates are due can be enough.

How do I keep a retainer from turning into a blank check? Make three things conditions of the agreement: every piece of work is estimated and approved by you before it starts, the team stops at the monthly budget and asks before going over, and you have access to the board where the work is planned.

What is the difference between a retainer and a bank of hours? A bank of hours is one way to price a retainer: a fixed number of hours a month, used or lost. Other models are a flat monthly fee with approved items, a dedicated developer, or on-demand billing per task or day.

Can I cancel a software maintenance retainer? You should be able to, on a notice period measured in weeks. Razoyo’s retainers run month to month, with 30 days’ notice to stop and 15 to change the budget, and once fees are paid you own the code we write for you.

Should the same team that built my software maintain it? Often, because they already understand it, which saves the cost of a new team learning the code. That is only true if they pass the same checks as anyone else: approval before work, a visible board, reviewed changes, and easy exit terms.

Talk it through

If you are comparing retainer proposals, or you already pay for one and are not sure what it buys, that is a free 30 minute conversation. Bring the proposal or the last invoice. We will run the Seven-Line Retainer Check on it with you, tell you which lines fail and what to ask for, and if the software is simple enough that you do not need a retainer at all, we will tell you that too. Schedule Free Consultation.

Paul Byrne is President of Razoyo, a software engineering firm in The Colony, Texas taking prototypes and constrained systems into production since 2011.