Sprints or retainers? How to choose the right way to work with a design partner

Fixed-scope sprints and monthly retainers both work well, just for different situations. A plain comparison of how each one works, where it shines and where it falls short.

Ibrahim

September 16, 2026 · 3 min read

A short orange running lane next to a long grey looping track

When a startup brings in outside design help, the conversation usually lands on one of two models. A sprint: a fixed piece of work, done in a set number of weeks, for a set price. Or a retainer: a monthly fee for ongoing access to a designer or a team, with the work decided as you go.

We should be upfront: we offer both, so we have no reason to push you towards either one. For some teams a sprint is clearly the better fit, and for others a retainer is.

How a sprint works

A sprint is built around one outcome. The details vary between studios, but most follow a similar shape:

You agree on a goal, such as a launch-ready MVP design, a new marketing site or a redesigned onboarding flow.
The scope, timeline and price are fixed before work starts.
The team works in short, focused cycles with regular check-ins.
It ends with a clear deliverable, and the engagement is over unless you choose to start another one.

A well-known version of this idea is the five-day design sprint developed at GV. Most studio sprints run longer than five days, but the principle is the same: a fixed time box and one clear question to answer.

GV’s sprint process in 90 seconds

How a retainer works

A retainer buys capacity rather than a specific result. You pay a monthly fee for a set number of hours or a dedicated person, and the work is prioritised week by week. It is closer to having a part-time member of the team than hiring for a project.

A whiteboard with a weekly plan and sticky notes — On a retainer, work is usually planned a week or two at a time. Photo: Unsplash

Where sprints work well

A clear goal with a deadline, such as a funding round, a launch date or a pilot with a customer.
Budget certainty. You know the total cost before you commit.
Forcing decisions. A fixed timeline makes it hard to put off choices about scope.
Trying out a new partner. A sprint is a contained way to see how you work together.
Something to show at the end. The result is concrete and easy to evaluate.

Where retainers work well

Continuous product work, where design needs to keep pace with an engineering team shipping every week.
Many small requests that are not worth scoping one by one.
Deep product knowledge. Someone who has been with the product for months makes better calls than someone arriving fresh.
An unpredictable roadmap, where priorities change as you learn.
Ongoing experiments, like landing page tests, where the next piece of work depends on the last result.

A grid of grey tiles with a raised block of orange tiles — A sprint is a defined block of time with a defined result. A retainer is the calendar around it.

The trade-offs that are easy to miss

Both models have downsides that rarely come up in a sales call.

With sprints:

Scope is fixed, so new ideas mid-sprint either wait or become a change request.
There can be a gap between sprints where context is lost.
The pressure of a fixed timeline can squeeze the time for testing with real users if it is not planned in.

With retainers:

Hours can go unused in quiet months, and you still pay for them.
Without clear goals, work can drift into small tasks that never add up to something bigger.
It is harder to measure what you got for the money.
Over a long period, the total cost can be higher than a series of focused projects, although the cost per hour is often lower.

Questions to ask before you decide

Can we describe what “done” looks like for this piece of work?
How often will our priorities change in the next three months?
Do we need a finished result, or ongoing capacity?
Who on our side will give feedback and make decisions, and how much time do they have?
How will we judge whether the engagement was worth it?

You do not have to pick just one

Many teams combine the two. A common pattern is to start with a sprint to build something specific and get to know a partner, then move to a retainer for the ongoing work that follows. The reverse also works: a retainer with a clear goal set at the start of each month behaves a lot like a series of small sprints.

Neither model is better in general. Sprints suit clear goals and fixed budgets. Retainers suit ongoing work and changing priorities. The right choice depends less on the partner you hire and more on where your product is right now.