Retainer vs Project-Based: Choosing the Right Agency Model

A retainer buys ongoing capacity: a recurring block of design or development time you can point at whatever comes up each month. A project-based engagement buys a fixed outcome: an agreed scope, delivered once, for an agreed price or set of milestones. The real difference isn't the paperwork — it's how work gets prioritized. On a retainer, priorities reset every cycle and scope stays flexible. On a project, scope is locked before work starts and the agency stays accountable to that fixed target until it ships.

Both models solve real problems, and most agencies offer both for a reason. The mistake is picking one because it's the one an agency happened to offer first, or the one a previous vendor used, rather than because it matches how your work actually shows up week to week.

How does a retainer engagement actually work?

A retainer is a standing agreement for a set amount of capacity — usually a number of days or hours per month — that renews on a fixed cycle. You are not buying a single deliverable. You are buying access to a team's time, which you and the agency then fill with whatever is most useful that cycle. That makes a retainer less like a purchase order and more like an ongoing working relationship, with a rhythm of planning, execution, and review that repeats every month or quarter.

What's included in a typical retainer scope?

Retainer scope is defined by capacity and category, not by a deliverable list. A design retainer might cover ongoing UI work, small feature design, design system upkeep, and one-off requests as they come in. A development retainer might cover bug fixes, small builds, integrations, and performance work. What changes month to month is which of those gets picked up first.

• A capacity number: a set amount of time available each cycle, not a task count.
• A category of work: the kinds of requests the retainer is meant to cover.
• A priority process: how you and the agency decide what gets worked on first.
• A reporting rhythm: a regular check-in on what shipped and what's queued.

How does a retainer handle work that wasn't planned for?

This is usually the real reason teams choose a retainer in the first place. A fixed-scope project has no natural way to absorb an urgent fix or an unplanned request without a change order. A retainer does, because the priority list is never locked more than one cycle out. Something urgent can simply move to the top of the next planning conversation instead of triggering a separate negotiation. The trade-off is that anything not urgent can keep sliding down the list if the agency and the client never agree on what actually counts as a priority, which is why a shared planning process matters more on a retainer than on almost any other part of the agreement.

How is a retainer usually priced?

Retainers are typically billed as a recurring fee for a set amount of capacity, renewing monthly or quarterly. The price maps to time available, not to a specific list of outputs — our guide on what actually drives design pricing covers how agencies think about scope and cost more broadly. Because the fee is tied to capacity rather than a fixed deliverable, the value of a retainer depends heavily on how clearly unused time and rollover are defined upfront, and on how disciplined both sides are about using the planning cadence instead of letting requests pile up unsorted.

How does a project-based engagement work?

A project-based engagement starts with a defined scope: a set of deliverables, a timeline, and either a fixed price or a milestone-based payment schedule. The agency is accountable to that scope until it's delivered, and the relationship has a natural end point once the work ships. Compared with a retainer, a project trades flexibility for certainty — you know roughly what you'll get, roughly when, and roughly what it will cost, before any design work begins.

What's included in a fixed-scope project?

Project scope is usually captured in a proposal or statement of work before anything is designed or built. It names the specific deliverables — pages, screens, a design system, a launch — along with what's explicitly out of scope. That boundary is what makes a fixed price possible in the first place, and it's also the part clients tend to skim past, which is where most disputes later start.

• A deliverables list: the exact pages, screens, or assets the project will produce.
• A timeline with milestones: phases with dates, often tied to payments.
• An approval process: who signs off at each phase before work continues.
• A change-order process: how anything outside the original scope gets priced and added.

How are project timelines typically structured?

Most fixed-scope projects move through the same broad phases, even though the names and lengths vary by agency and by how big the project is.

1. Discovery: confirming goals, audience, content, and constraints before any design starts.
2. Design: concepts, review rounds, and sign-off on direction before build begins.
3. Build: development or production against the approved design.
4. Launch and handoff: final QA, go-live, and delivery of files or access.

Each phase is usually a milestone tied to an approval and, often, a payment — which is part of why scope changes mid-project are hard to absorb cleanly. Moving a deliverable in or out after a phase is approved tends to ripple into every phase after it.

How is a project-based engagement priced?

Most project-based work is priced as a fixed fee for the agreed scope, sometimes split across milestones, or occasionally billed hourly against a capped estimate. Because the price is set against a specific scope, anything added afterward needs its own conversation — that's the change order, and it's worth asking how an agency handles it before you sign anything, rather than discovering the process for the first time mid-project.

Retainer vs. project-based: what actually changes between them?

How much day-to-day involvement does each model need from your team?

A retainer generally asks for lighter, more frequent involvement: a short planning check-in at the start of each cycle, quick answers to questions as work moves, and a review at the end. Because scope resets often, there's rarely a long stretch where your input isn't needed somewhere.

A project asks for the opposite pattern: long stretches where the agency works largely on its own, punctuated by concentrated review moments at each milestone. Those review windows matter more on a project, because sign-off at one phase is usually what allows the next one to begin — a slow approval can push the entire timeline back in a way that a retainer, with its shorter cycles, is less exposed to.

When does a retainer make more sense?

A retainer fits work that doesn't have a natural finish line: ongoing product design, a design system that needs regular upkeep, a marketing site that needs small updates every week, or a backlog of fixes and improvements that never fully empties. It also fits teams that want a design or development partner on call without re-scoping a new project every time something small comes up. If your list of requests keeps growing faster than any single project could absorb, that's usually a sign the work has outgrown a project shape.

When does a project-based engagement make more sense?

A project-based engagement fits work with a clear finish line: a new website, a rebrand, a product launch, an app redesign. If you can describe the deliverable and roughly when you need it, a fixed scope gives you price certainty and a defined timeline — two things a retainer, by design, doesn't offer. It also suits situations where budget has to be approved as a single number upfront, since a fixed price is easier to plan around than an open-ended monthly fee.

Can you switch between a retainer and a project-based model?

Yes, and it's common. Many engagements start as a project — a new site, a redesign — and move into a retainer once the deliverable ships, to cover ongoing updates and small requests. The reverse also happens: a retainer surfaces a bigger initiative, like a full rebrand or platform migration, that gets pulled out and scoped as its own fixed-price project so it has a dedicated timeline and budget instead of competing with everything else in the monthly queue.

The switch works best when it's treated as a real scoping exercise rather than a label change. Write down what the new engagement covers, even briefly — our guide to writing a design brief covers what to include, and the same structure works whether you're scoping a first project or converting a retainer into one. Skipping this step is the most common reason a switch causes friction: the old assumptions from one model quietly carry over into the other, where they no longer apply.

Which model fits your situation? A quick checklist

What questions should you ask an agency before signing either model?

The contract type matters less than the details underneath it. Before signing a retainer or a project agreement, ask how the specific model you're considering actually gets managed day to day — our guide on questions to ask before hiring a web design agency covers the broader vetting process; the questions below are specific to the engagement model itself.

What are common mistakes when choosing between the two models?

• Picking a project when the work has no real end. Forcing an ongoing need into a fixed scope leads to constant change orders, and a project that technically ships but never quite closes because new requests keep arriving.
• Picking a retainer for a one-off launch. A retainer's flexible priority list works against you when you need one thing, delivered by one date, with nothing else competing for attention on the same list.
• Not defining what happens to unused capacity. Retainers without a clear rollover or credit policy quietly lose value every cycle no one asks about it, until months of unused hours have simply disappeared.
• Leaving change orders undefined on a project. Without an agreed process for pricing scope changes, creep gets absorbed informally until either the timeline or the relationship breaks under the weight of it.
• Assuming the model is permanent. Treating the first agreement as fixed for the life of the relationship, instead of revisiting it as the work itself changes shape over time.
• Comparing the two on rate alone. A retainer's monthly fee and a project's fixed price answer different questions about your work, so comparing them purely as numbers, without accounting for scope and pace, tends to compare the wrong things against each other.

The takeaway

A retainer and a project-based engagement are both normal ways to work with a design or development agency, and neither one is the default choice. The right one comes down to whether your work has a finish line: build toward one with a project, or keep a partner on call with a retainer when the work doesn't stop. If you're not sure which fits what you have in mind, talk it through with us before you scope anything.