All insights

One time build or a monthly retainer, and how to tell which you are actually buying

A retainer is a subscription to attention. If nothing needs attention, you are paying for availability you never call on, and the invoice arrives anyway.

The answer, including the part that costs us the retainer

Buy a one-time build when the process is settled, the systems it touches are stable, and somebody inside your business can make small changes afterwards. Pay a monthly retainer when the work genuinely keeps changing, when the systems it depends on move underneath it, or when nobody internal can respond if it stops at an awkward moment. If you cannot name what a retainer would do in a typical month, it is buying availability rather than work, and you should not sign it.

A project fee buys an artefact. A retainer buys attention. Those are different purchases and comparing their prices without saying which is which is how businesses end up paying monthly for a system nobody has touched since the second week.

Ask any provider proposing a retainer to describe a typical month in it. A clear answer is a good sign. A vague answer about ongoing optimisation is a subscription looking for a justification.

When buying it once is the better deal

This is a real and common case. A workflow connecting two stable applications, doing a job the business has done the same way for years, does not need a monthly relationship. It needs to be built properly, documented, and handed over with the accounts in your name.

The condition that makes it work is internal capability, and it is smaller than people fear. Somebody who can log into the automation platform, read what the workflow does and change a text template or an email address covers most of what actually gets requested after launch. That person does not need to be technical, only willing.

There is a second reason to prefer buying once. A project has a definition of done, so both sides know what finished looks like. Retainers have no such moment, which is why they drift into vague activity when the interesting work has been completed.

When a retainer is the honest arrangement

Some systems do need continuous attention, and pretending otherwise leads to the worst outcome of all: a business that owns automation nobody watches, discovering months later that a workflow has been failing silently since a platform update.

Change is the main driver. Applications update, fields get renamed, messaging platforms revise their rules, and models are deprecated. None of that appears on your roadmap, and all of it lands on systems you depend on. Somebody has to notice, and noticing is a service rather than a build.

The second driver is consequence. When a broken workflow means enquiries silently stop reaching anyone, the value of a retainer is response time rather than hours delivered. That is a legitimate thing to buy, provided the agreement says how quickly and by whom.

What each model actually includes

The disagreements after signing are almost always about the last two rows, so settle them before the first.

CriterionOne-time buildMonthly retainer
What you are buyingA finished system, documented and handed overContinued attention and a response time
Definition of doneExplicit, and both sides know itNone, which is why scope needs writing down
Who notices a silent failureYou do, if you set up the alertsThem, if monitoring is actually in the agreement
Cost when nothing changesNothingThe same as any other month
Small changes after launchQuoted individually, which adds frictionIncluded, which is most of the practical value
What you keep if it endsEverything, if the contract says soEverything, if the contract says so. Check.

The arrangement that fails both ways

The worst version of this is a retainer with no stated deliverable and no named owner on either side. Nobody can say what was done last month, nobody can say what should be done next month, and the relationship survives on politeness until somebody looks at the invoices. If a proposed retainer cannot describe a typical month in specifics, that is the arrangement being offered.

The one-time build has its own failure. A system delivered without documentation, with the accounts in the provider's name and the credentials in their password manager, is not owned by you no matter what the invoice says. It is a rental with a single payment, and you find out when you try to change something.

There is also a case for neither. If the process is about to change, or the department is being reorganised, or you are switching CRM next quarter, do not buy either. Wait, and spend the interval writing down how the work is actually done, which is the input both arrangements need anyway.

How to decide, and what to insist on

Write down what you would ask for in each of the next six months. If you can fill three of them with specific work, a retainer is buying something real. If you cannot fill one, buy the build, take proper handover, and agree an hourly or per-change rate for the occasional request. Many businesses land on a middle arrangement: a project fee for the build, then a small monitoring agreement that covers watching and fixing rather than building.

Whichever you sign, insist on the same three things. Accounts and licences in your name. Workflows and credentials somewhere you can reach without asking. Written documentation of what each system does and who to call when it stops. Ask the plain question before signing: if we stop next month, what do we keep? The answer tells you more than the price does.

The six-month test

List the specific work you would request in each of the next six months. Empty months are the honest argument against a retainer, and full months are the honest argument for one.

The six month test, answered from the supplier's side of it

The six month test at the end is the right one, and this is what it looks like from the other side. A one time build follows a published shape: the audit takes the first week, the system is live inside a fortnight, and the handover documentation and training land with it. After that, if you cannot fill three of the six months with specific work, there should be no retainer at all, and a supplier who will not say so is selling availability. Where somebody in-house can make the small changes, buying once is the better deal, and saying that costs us the recurring invoice.

No price is published on this site, and the reason maps neatly onto the two models. A build's number moves on the count of systems, the volume and how much of your process exists in writing. A retainer's number moves on how much genuinely needs attention, which is a different question and usually a smaller one than a first quote implies. Asking a supplier which of those two they have priced is the quickest way to find out what is actually being sold.

Two things should not vary between the models. You own the system either way, with the accounts, the workflow definitions, the documentation and the data in your name, so a retainer that ends leaves a working system rather than a stopped one. And the stop is yours either way: money, pricing, anything published in your name and any serious complaint wait for human approval, with a case outside scope handed to a person. A retainer that includes somebody being the escalation is buying attention, which is legitimate and should be named rather than folded in.

The arrangement here is month to month, which is the version of a retainer that has to be re-earned rather than served notice on. Wobble is based in Karachi and answerable for what it operates across 25 engagements in six countries, with the work published with figures rather than described: 94 units delivered in the first two months at Quillon, more than 500 calls a day at Big Texas Land Buyers. Haad owns growth and client solutions and takes the conversation about which of the two models you actually need.

Common questions

Is a monthly retainer worth it for automation?

Only when something actually changes each month, or when a failure costs you money within hours. If the systems are stable and somebody internal can make small edits, a one-time build with documented handover is the cheaper and cleaner arrangement. Ask what a typical month contains before you sign anything.

What should a retainer include?

A stated response time, monitoring with alerts that reach a named person, a defined allowance of change work, and a written record of what was done each month. Without those it is a subscription to availability, which is occasionally worth buying and should at least be recognised as what it is.

Can I take over maintenance myself after a build?

Often yes, and it is worth planning for. Someone who can log into the platform, read a workflow and change a template or an address handles most post-launch requests. Ask for a handover session and written documentation as part of the build rather than as a favour afterwards.

What breaks in an automation if nobody maintains it?

Usually something outside your control. An application updates and a field disappears, a credential expires, a messaging platform revises its rules, or a colleague renames a column the workflow depends on. The damaging part is that these often fail silently, so set up alerts even if you buy no support at all.

How do I compare a project quote against a retainer quote?

Ask which parts of each number are one time and which repeat, and across how many months. Then compare over two or three years rather than at delivery. A project fee plus occasional change requests often costs less than a retainer over that horizon, unless the retainer is genuinely full of work.

What if a provider only offers retainers?

That is a legitimate business model and a reason to check the fit rather than a red flag by itself. Ask what happens in a quiet month and whether unused time carries forward. If the honest answer is that quiet months are simply billed, decide whether the response time alone is worth that to you.

See where this applies to your business

The AI Readiness Call is a short, free conversation about where automation would actually pay back in your business. The call is free. The diagnosis is not.

Book AI Readiness Call