How a development retainer works

A retainer is an agreed number of engineering hours per week, reserved for you, spent on whatever the product needs that week. Ten hours, twenty hours, whatever the contract says. No scoping round before each task, no estimate for a two-hour change, no waiting for a slot.

That is the whole idea. It is also the arrangement most likely to quietly stop being worth the money, which is why the honest version is worth writing down.

When a retainer is the right shape

You own a product that is live and earning. Someone is using it today. Things break, people ask for changes, and the list never empties.

The work is real but not projectable. You cannot write next quarter's scope because you do not know yet what next quarter needs. A bug on Tuesday, a campaign page on Thursday, a slow query someone finally noticed on Friday.

You need the same people each time. Most of the value in a long engagement is knowledge nobody wrote down: why that rule exists, which client has an exception, what breaks when you touch the content model. A supplier who rotates staff never accumulates it, and you pay for the rediscovery every time.

The queue is steady but not full time. Not enough to justify hiring, too much to keep asking for one-off quotes.

When it is not

Be suspicious of anyone who sells you a retainer in these cases.

You have one defined project. A rebuild, a migration, a new product. Buy the project, fixed-price against a written scope, and decide about a retainer afterwards.

Nobody on your side owns the backlog. A retainer with no product owner turns into hours spent on whoever asked last. That is not a supplier problem and no contract fixes it.

You would not use the hours. If the honest answer is five hours of real work a month, a retainer is a subscription to availability you are not using. Pay hourly instead.

What the hours actually go on

The list is wider than most people expect, which is the point of reserving capacity rather than buying tasks.

Development and new features. The visible half, and usually not the largest.

Bug fixes. Including the ones nobody has reported yet, found while doing something else.

Design changes. New sections, seasonal layouts, a page that has stopped matching the brand.

Content work. Loading, restructuring, migrating content, and building the tools so your own team can do it without a release.

Performance. Page speed, Core Web Vitals, slow queries, images, the third-party scripts that accumulate without anyone deciding to add them.

Marketing and experimentation. Landing pages, campaign work, tracking that reports real numbers, A/B tests set up so the result means something.

Data and analysis. Reading the database rather than guessing: what sells, what is abandoned, which cohort returns, which page loses people.

Infrastructure cost. Server and service spend, reviewed. An oversized instance, a log retention nobody set, a storage bucket from an experiment two years ago. This one regularly pays for a chunk of the retainer itself.

Platform maintenance. Dependency updates, API deprecations, security patches, and the certificate that would otherwise expire on a Sunday.

Being available. Some weeks the most valuable thing is that someone who knows the system answers within the hour.

The five questions to settle before signing

Ask these of us or of anyone else. The answers tell you more than the rate does.

What happens to hours I do not use? There is a real answer in every contract: they roll over, they expire, or they are capped at a number. Any of the three can be fair. What is not fair is finding out afterwards.

What happens when I need more than the agreement? A good answer names the overflow rate and how much notice it takes. A bad answer is "we will find a way", which means either a surprise invoice or a missed date.

Who exactly does the work? Names, not a team size. A retainer where the engineer changes every month is an expensive way to pay for onboarding.

What do I see? You should get, every month, what was done, how long each thing took, and what is queued. If a supplier cannot show you where the hours went, the hours are not the product you are buying.

How do I leave? Notice period, what you get on the way out, who holds the repositories and the accounts. Any arrangement you cannot exit cheaply will eventually be one you want to exit.

How ours works

Hours per week agreed in the contract, up to twenty, reserved for you. Store and application work is charged at $35 per hour, so the retainer is that rate with capacity reserved rather than a separate price list.

You get a written report: what was done, the time against each item, what is in the queue and what we think should be next. Repositories, servers and accounts stay in your accounts throughout, because a retainer should be something you continue by choice rather than because leaving is hard.

The engineers stay the same. That is not a courtesy, it is the only reason the arrangement gets cheaper for you over time: after a year the same change takes a fraction of the hours it took in month one, and you keep the difference.

Our longest retainers have run four years, on Fine Matter since 2022 and Completedworks since 2024. If you have a product that is live and a list that never empties, tell us what is on it and we will say honestly whether a retainer is the right shape or whether you should just buy the project.