Buy a project when the work has an end you can describe. Move to a retainer when the value is somebody being available and accountable week to week rather than in a deliverable. The version that wastes money is a retainer with no named outcome, because nobody can tell whether it is working.
Work it out in a minute
Four numbers. Shows how much work is sitting still, waiting on you.
What we take on
A project is right when the end is describable
A site, a migration, an assessment, an integration, a set of documents. If you can write the sentence that says it is finished, buy it as a project and pay for that sentence.
A retainer is right when availability is the value
Somebody carrying a standing responsibility: the close lands on a day, the reports go out, the queue gets worked, the thing that broke gets fixed before you notice. There is no finish line and that is the point.
Name an outcome either way
A retainer without one is a subscription to somebody being nearby. Put the standing commitments in writing: what happens every week, what happens every month, and what response time looks like.
Watch what happens after the project ends
A build that nobody can run is a project half bought. Ask who operates it, what is written down, and what the first month after handover looks like.
Most engagements are both, in order
A project first, because it produces something and proves the working relationship. Then a retainer for whatever has to keep running, once you both know what that actually is.
Judge a retainer every quarter
Ask what changed in the last three months and what is different next quarter. A retainer that cannot answer that has become a habit, and habits are easy to keep paying for.
How to decide, from the paying side
Start by writing the sentence that says the work is finished. If you can write it, buy a project. If every attempt turns into "and then it keeps going", the work is standing and a retainer is the honest shape for it.
The advantage of a project is that both sides know what done means, so both sides can tell whether it went well. The disadvantage is that a project ends and something usually still has to be run afterwards, which is where the second decision arrives.
The advantage of a retainer is coverage and speed: somebody already knows your systems, and a question on Tuesday gets an answer on Tuesday. The risk is drift, where the arrangement continues because it always has.
Guard against drift with two sentences in the agreement. What is committed every month, and what a quarterly review looks at. Both are easy to write at the start and awkward to introduce a year in.
On price, compare like with like. A project has a scope and a number. A retainer has a monthly number and an implied scope, and the implied part is where the disagreements live. Write the implied part down.
The sequence that works for most companies is a project that produces something real, then a retainer sized to whatever genuinely needs a standing owner. Starting with the retainer means paying for availability before knowing what it is for.
Questions we get
Which is cheaper?
For defined work, a project, because you are paying for an outcome rather than for time. For standing work, a retainer, because the alternative is a series of small projects that each carry their own setup.
The expensive option is a retainer bought for work that had an end.
What should a retainer actually commit to?
Named recurring outputs, a response time, and a review. Something like: the month closes on the fifth business day, reports out by the seventh, replies within one business day, and a quarterly conversation about what changed.
If none of that can be written, the work is probably a project.
Can we start with a project and see?
That is the usual and the sensible order. A first project shows you how somebody scopes, communicates and hands over, which is most of what you are actually buying.
It also tells you honestly whether anything needs a standing owner.
How do we get out of a retainer?
Cleanly, if it was set up cleanly: notice in the agreement, and a handover list agreed at the start rather than requested at the end. Access, documentation, the runbook, the accounts.
Ask what leaving looks like before you join. The answer tells you a lot.
Is a retainer just a way to lock us in?
It can be, and the test is whether the agreement names what you get rather than how much time somebody spends. Named outputs and a review date mean it has to keep earning its place.
Hours with no outcome attached is the version to avoid.
How does this practice work?
Projects are scoped to something you can describe and end on a date we name. Where work has to keep running we stay on as the outside team, and you pick that at the end rather than at the start.
What gets built is documented so it can be handed over, whichever you choose.
More in the guides and every answer in one place.
Shaheer leads the work, with engineers, writers, filers and analysts behind him. C-suite operations for a San Francisco AI company, Six Sigma on the process side, Anthropic certified on the Model Context Protocol, ten years across eight industries. See what we have built