Developer Retainer Agreement: How Retainers and Prepaid Hours Work

A developer retainer agreement is a monthly arrangement where you pay for a set number of hours and the developer keeps that time free for you. A block of prepaid hours works the other way round: you buy the hours upfront and draw them down whenever there's work. If your software needs attention every month, a retainer usually fits better, while prepaid hours are simpler and often cheaper when requests come in bursts.

I maintain and extend client systems myself, so weigh my take with that in mind. I've tried to be just as clear about when neither model is right for you.

The short answer: retainer or prepaid hours?

My test is simple. Open your issue tracker, or the list in your head, and ask whether you could fill the next three months with real work. If yes, and the software keeps evolving, a retainer fits. If not, buy a block of hours and see how many you actually use.

Ongoing agreements are only one way to pay for development. For the bigger picture, including fixed-price projects and paid discovery phases, see my full guide to software development costs.

How each model works

Monthly retainer

You agree on a fixed number of hours per month, say 8, 16 or 40, and pay the same amount every month, usually at the start. The developer plans their calendar around it. That reserved capacity is what you're really paying for: your tasks don't queue behind new projects.

A retainer works best with a shared, prioritized list of work and a short check-in every two to four weeks. Before you sign, get answers to three questions:

• What happens to unused hours? Some contracts let them expire at month end. Others let you roll them over for one or two months. Rollover sounds better, but hours can pile up, and a developer can't deliver three months of hours in one.
• What does overage cost? Usually the same rate or slightly more. Agree that the developer checks with you before going over.
• How long is the commitment? A rolling agreement with one to three months' notice is a sensible starting point. Save annual terms for after you've worked together.

Some retainers are based on responsibility rather than hours: a fixed fee for keeping the system patched and monitored, however long that takes in a given month. That's closer to a support agreement and pairs well with an hourly retainer for new features.

Prepaid hours

You buy a block, for example 10, 20 or 50 hours, and each task is deducted from the balance. When it runs out, you buy another. There's no monthly cost and no commitment beyond the block.

The catch is that the developer's time isn't reserved. If they're busy with a project, your request may wait a few days. That's fine for a new report column, not for a bug that stops customers from paying. Check three terms: the expiry date, the smallest billing increment (15 minutes and a full hour per task add up very differently), and how you see what each hour was spent on.

What a typical retainer month looks like

It's easier to judge a retainer when you can see where the hours go. The table below is an illustration, not a specific client: two days (16 hours) a month on a web app that's live and still growing.

Two things stand out. Feature work is the biggest line, and it should be: a retainer spent only on bugs and updates is really a support agreement. And the buffer isn't waste. It's what stops a surprise from pushing the planned feature into next month.

The cost is hours times rate. As an illustration, at €120 an hour, 16 hours comes to €1,920 a month, excluding VAT. Rates vary a lot across Europe, so compare with what freelance developers in Denmark charge per hour and with local rates where you are.

If 16 hours is more than you need, a smaller retainer of 6-8 hours can focus on updates and small improvements. If you regularly need more than a week a month, you're heading toward a different calculation, covered further down.

What drives the monthly cost

The total is hours times rate, but several things push both numbers:

• Response time: if you need a reaction within hours, the developer has to keep time free every day. That costs more than a next business day response.
• Familiarity with the code: a new developer needs time to learn your system. It's a one-off, but it usually lands in the first months.
• State of the codebase: outdated packages, no automated tests and missing documentation slow every task down.
• Commitment: some freelancers offer a lower rate for a longer term. Check whether the discount is worth the lock-in.
• What's included: hosting, monitoring tools and meeting time may be part of the fee or billed separately. Get it in writing.

If your work comes as large, well-defined chunks, pricing each one separately may be cheaper. I compare the two approaches in fixed price vs hourly rate. And if you're weighing a retainer against hiring, see how freelancer, agency, in-house and offshore costs compare.

Retainers with a developer in another country

Plenty of retainers cross borders, and a few practical points are worth settling upfront.

Time zones. Denmark runs on Central European Time, which is never more than an hour off other EU capitals or London, so your working days overlap almost completely. With the US East Coast, six hours behind, the overlap is only a couple of hours during their morning. Define response times in your business hours, not the developer's.

Currency. Agree on the invoicing currency in the contract. EUR is a common choice for cross-border work in Europe. If your company isn't in the eurozone, decide who carries the exchange rate risk.

VAT. When a developer in one EU country sells services to a business in another, they don't usually charge VAT. You account for it in your own country under the reverse charge procedure. Rules differ for customers outside the EU, so check with your accountant. This isn't tax advice.

Ownership. State which country's law applies and that the code you pay for is yours. That matters more, not less, when you're far apart.

Setting up a retainer in five steps

1. List the next three months of work. Bugs, requests, updates. The list tells you whether you need a monthly rhythm or just a block of hours.
2. Estimate the hours with the developer. Ask for a rough estimate per item and add 15-20% for the unexpected.
3. Pick the model that matches the rhythm. Work every month points to a retainer. Work in bursts points to prepaid hours.
4. Put the terms in writing. Use the checklist below. If you also need guaranteed response times, updates and backups, add a support agreement. My software maintenance agreement checklist covers what that should include.
5. Review after three months. Did you use the hours? Did the important work get done? Adjust up or down instead of carrying on with a guess.

When neither model fits

An ongoing agreement isn't always the answer. In these cases I'd point you elsewhere:

• You have one well-defined project. A new customer portal or a large integration should be priced as a project, ideally after a short discovery phase. Retainer hours are a poor way to steer a big build with a deadline.
• You need a full-time developer. If you use 80-100 hours a month, year after year, hiring or building an in-house team may cost less and give you more continuity.
• Nobody on your side has time to prioritize. A retainer without a clear owner ends in unused hours or hours spent on the wrong things.
• The system is small and stable. A website with a handful of changes a year is usually fine with pay-as-you-go work and managed hosting.
• You need 24/7 on-call cover. One freelancer can't credibly promise that, whatever the model. You need an agency or managed service provider with an on-call rota.

Next steps

Start with your list of work. It will tell you more about retainer vs prepaid hours than any rate card. Once you have it, ask two or three developers to propose a monthly budget, and compare their terms on unused hours, response times and notice side by side.

To see how I work with existing systems, read about maintenance and ongoing development. My rates are on the pricing page.

Frequently asked questions

What's the smallest retainer that makes sense?+

There's no hard minimum, but below roughly 5-8 hours a month it's hard for a developer to stay familiar with your system. Too much of each month goes into re-reading code instead of shipping changes. If you need that little, a block of prepaid hours or paying as you go is usually cheaper for you.

Can I switch from prepaid hours to a retainer later?+

Yes, and it's often a good way in. Three to six months on prepaid hours shows how much work you really have and how often it comes. If usage is steady and you want faster help, that's the moment to switch. Agree in advance what happens to any hours left on the block.

Should a retainer have a lower hourly rate than ad hoc work?+

Sometimes. The developer gets predictable income and less admin, so some offer a small discount for a commitment. Others keep the same rate and give you priority instead. Both are fair. Judge the whole deal: rate, response time, rollover rules and notice period together, not the hourly figure alone.

What happens to my retainer during the developer's holidays?+

It should be in the contract. A common approach is that holidays are announced well in advance and the hours are either spread across the surrounding months or deducted from that month. In Denmark, a summer break of around three weeks, often in July, is common, so plan for it. Also ask who you can contact if something breaks while the developer is away.