Software development without a retainer: how it works

Ask most agencies for help with your software and the answer arrives as a monthly fee. A number of days a month, a minimum term, thirty days' notice.

That is a legitimate way to buy development and for some businesses it is the right one. But it is presented as the only way far more often than it is actually the best fit, and it is worth understanding why before you sign one.

What a retainer is actually for#

It smooths income for the supplier, and that is not a criticism.

A firm with salaried staff has to pay them in a quiet month as well as a busy one. Work arriving unpredictably is the hardest thing to run a payroll against, so the retainer converts lumpy demand into a flat monthly figure they can plan around. It is a sensible answer to a real problem.

The question is whose problem it solves. If your demand is also flat, the retainer suits you both. If your demand is lumpy, you have taken on the supplier's smoothing problem in exchange for a discount you may not be using.

The hours that quietly disappear#

Here is the thing to check before anything else in the contract, because it is where most of the value goes: do unused hours roll over, and for how long?

Very often the answer is that they do not, or that they roll for one month only. Which means a quiet August is paid for and gone. Businesses with genuinely seasonal demand can pay for a third of their allocation across a year without noticing, because the invoice looks the same every month and nobody reconciles it against what was delivered.

Two other clauses worth reading properly. What counts as usage, since some agreements bill meetings, calls and project management against your hours, and those can consume a surprising share of a small retainer. And what happens when you exceed it, because the overage rate is sometimes considerably higher than the effective rate you are paying inside the retainer.

When a retainer genuinely is right#

It would be dishonest to write all that and imply nobody should have one.

You need guaranteed availability. If something breaking costs you money by the hour, paying to be at the front of a queue is rational. That is what you are buying, and it is worth real money.

Your demand is continuous and predictable. A steady stream of work every month is exactly the shape a retainer fits.

You need them to hold context. Some systems are complex enough that the cost of somebody getting back up to speed each time is a genuine expense, and continuous engagement avoids paying it repeatedly.

Your finance team needs a flat number. Budget predictability has a real value even when the arithmetic is slightly worse.

If none of those apply to you, you are probably paying for smoothing you do not need.

What the alternative actually looks like#

Buying by the job means the work is priced before it starts, you approve each piece, and there is nothing to pay between jobs.

The mechanics that make it workable are worth naming, because "no retainer" on its own tells you nothing:

• A price in writing before anything begins, which does not move afterwards. Without that, buying by the job is hourly billing with extra steps.
• No minimum, so a small job is not rounded up to something worth invoicing.
• A way in that is not a meeting. If every job starts with a call, the overhead comes back and you pay it in time instead of money.
• Your accounts in your name from the start, so stopping is not an event that needs negotiating.

The honest trade-off is availability. You are one of several clients rather than the only one, so if something breaks at nine on a Friday you are not buying a guaranteed response. For most businesses, most of the time, that is a price worth paying for not funding quiet months. For some it is not, and those are the businesses that should have a retainer.

The question that settles it#

Write down the development work your business actually had in the last twelve months. Not what you would like to do eventually. What was real.

Most small businesses doing this honestly land somewhere between fifteen and sixty days a year, and it is lumpy: a burst in spring, nothing over the summer. Put your current or proposed retainer next to that list and work out what you paid per day of work actually delivered.

If the number is close to the day rate, the retainer is doing its job. If it is two or three times the day rate, you are buying insurance, and you should decide deliberately whether that is what you want rather than finding out by accident.

What we do#

We work job by job. You describe what you need, it gets graded by size, and you get the price in writing before anything starts. Nothing begins until you approve it, and there is nothing to pay between jobs.

No retainer, no minimum term, no notice period, and no minimum job size. A business with ten days of work a year is a perfectly good client and so is one with a hundred.

Everything is in your name from the first day: the repository, the hosting, the domain, every account the system runs on. On the code we keep the copyright and you hold a perpetual licence to use it for your project, change it, and have anybody at all change it, which does not lapse when we stop working together. There is no exit to negotiate because there is nothing to unwind.

And if it turns out you do need guaranteed availability, we will tell you that a retainer elsewhere fits you better. We would rather say it than sell you a shape that does not fit.