A retainer is not a discount on a project. It is a different shape of work entirely: instead of buying a defined deliverable, you are buying a slice of a designer's month, on call, for whatever comes up. That difference is worth being precise about before signing one, because the two models solve different problems and pricing them the same way is where most of the confusion starts.
What the retainer model actually is
A design support retainer is an outsourced replacement for an in-house designer, sized to the work you actually have rather than a 40-hour week. Banners for a campaign, a new landing page section, a tweak to the pricing page, slides for a board deck, a one-off social asset. None of it is large enough to scope as its own project, and all of it recurs. The retainer bundles that recurring, unpredictable volume into a monthly relationship: a set number of hours or requests, a queue, a turnaround time, and a designer who already knows your brand instead of relearning it every time something small comes up.
The value is not the individual banner. It is not re-briefing a new freelancer every three weeks, not re-explaining the brand guidelines, not waiting two weeks for a proposal on a task that should take two days.
Who the retainer actually benefits
The honest audience is teams with real, recurring design need that still does not add up to a full role. A marketing team of three running monthly campaigns needs banners, a landing page variant, and deck slides for the sales team, but not forty hours of design work a week, every week. Hiring in-house for that volume means paying a full salary for a partially full calendar. Hiring a new freelancer per task means losing consistency and paying an onboarding tax every time.
The retainer works because it needs a mix of skills, not depth in one. A web tweak on Monday, a pitch deck on Wednesday, a brand-consistent banner set on Friday. Few in-house hires cover all three well; an agency retainer does, because the work is spread across people who already specialize.
When a one-off project fits better
Not every design need is recurring, and forcing a one-time job into a retainer wastes money on both sides. A new website, a rebrand, a single investor deck, a product launch page: these have a start, an end, and a scope you can write down in a paragraph. Price and scope that as a project. You get a fixed cost, a fixed timeline, and no ambiguity about what is included.
The test is simple: if the work stops mattering the day it ships and nothing similar is coming next month, it is a project. If a similar request will land again in four weeks, whether or not you can name it yet, it is retainer territory. Teams that guess wrong in the project direction end up re-briefing a new vendor every time something small comes up. Teams that guess wrong in the retainer direction end up paying monthly for a slot they use twice a year.
The real risk: no one owns the queue
The retainer model breaks down for one reason more than any other: nobody on the client side is clearly responsible for deciding what goes into the queue and in what order. Requests arrive from marketing, from sales, from the founder, each one reasonable on its own, each one submitted as if it were the only thing on the list. The designer has no way to tell which request actually matters this week, so the queue fills with everything and nothing gets prioritized.
This is fixable, but only on the client side. A retainer works when one person owns it: collects requests, ranks them, and is the single point of contact the agency checks with when two things compete for the same week. Without that owner, the retainer does not fail loudly. It just quietly delivers less than the hours paid for, because half the time goes to sorting out what should happen first instead of doing the work.
Deciding between the two
Look at your last three months of design requests, not your predictions for the next three. If they were scattered across web, brand and decks, arrived without much warning, and someone had to scramble for a freelancer each time, that is a retainer pattern. If the last big ask was one thing with a clear finish line, that is a project. Most teams eventually use both: projects for the one-time builds, a retainer to keep everything else moving between them.
If you are weighing which one your team actually needs, tell us what the last few months of requests looked like and we will size it honestly, project or retainer. Details on how we run ongoing work are on the design support page.
