Better work starts when we stop starting over

Most of what makes a piece of design right is unwritten. Which competitor the board is quietly measuring themselves against. Which word the founder has banned. Which page actually earns the enquiries, and which one everybody talks about but nobody visits.

None of that arrives in a brief. It accumulates — and when the relationship ends at the end of a project, it is thrown away with it, then paid for again the next time somebody new is hired.

Kept, it changes what a brief has to contain. "The usual, but for the trade side" is a complete instruction to somebody who already knows the product, and a fortnight of discovery to somebody who does not.

The first piece of work with anyone is the slowest, and it should be. Type has to be chosen, a grid decided, components drawn, tone argued about, approvals routed through people you have not met.

The second piece inherits all of it. So does the tenth. What was a fortnight of setup becomes an afternoon of extending something that already exists, and the time saved goes into the part that was always the point — whether the thing is any good.

That is the practical case for continuity. Not that anyone works faster under a retainer, but that less of the work is spent rebuilding a starting position that was already reached months ago.

Requirements rarely stay in one discipline. A quarter that starts with a landing page ends up needing a component library, then a campaign, then a rethink of how the enquiry flow actually behaves on a phone.

Under a project arrangement each of those is a new conversation with a new supplier, each starting at zero. Under a retainer they are the same arrangement pointed somewhere else — brand, web, interface, product or campaign, decided month by month against what is actually in front of you.

It is worth saying what this is not. It is not unlimited design, and the days are finite. What it removes is the procurement round in the middle, not the need to decide what matters most.

The weakest version of a retainer is a queue: briefs in one end, assets out the other, nobody asking whether the brief was right. That arrangement produces a great deal of work and very little progress, and it is the reason some teams have tried one and concluded they do not work.

The useful version is the opposite. Somebody who knows the product well enough to say that the page is not the problem, that the two things being asked for contradict each other, or that this has been tried before and here is why it did not hold.

That judgement is the part that genuinely compounds. It cannot be bought in for a fortnight, because it is made of everything learned in the months before — and it is worth more than the extra pair of hands most retainers are sold as.

This works alongside an internal team rather than in place of one. Most teams do not need every discipline permanently on staff; they need the ones they are missing, available when the work calls for them, and gone from the payroll when it does not.

The useful position is a slightly awkward one: close enough to the business to know how it really works, far enough outside it to still notice what everybody internal has stopped seeing. Familiarity is what makes the work fast, and it is also what dulls the questions, so the distance is worth protecting deliberately.

In practice that means being in the standing call and on the board, and still being the ones who ask why a thing is being done at all.

Systems decay fastest at the handovers. A component library built by one supplier and extended by the next drifts within two quarters — two type scales, four button variants, a spacing system nobody can explain.

Kept in one place, the opposite happens. Decisions get reused rather than relitigated, the system gets tightened instead of forked, and the reasons behind the odd-looking choices survive the person who made them.

Over a year that difference is not stylistic. It is the difference between a product that feels designed and one that looks like a record of everyone who has touched it.

First, we get close. A short onboarding to learn the product, the brand, the standards and — as much as any of it — how your team actually works, who decides, and how feedback really travels.

Then we set the rhythm. How work enters the pipeline, how competing priorities get settled, how often we speak. A shared board and a standing call is usually the whole of the machinery; anything heavier tends to become the work rather than serve it.

Then we keep making. Work moves without rebuilding context for every brief, and the fixed days get pointed wherever they are most useful that month. Every quarter we look back at what those days actually bought, and change where they go if the answer is unconvincing.

This makes sense for teams with a steady stream of design work rather than one defined thing: an internal marketing or product team that needs capacity it does not have, a business changing quickly enough that the work never really stops, or anyone tired of sourcing and briefing somebody new every quarter.

It does not make sense for everyone. If you need one identity, or one site, and then nothing for eighteen months, a project is the honest answer and costs less. A retainer only pays for itself where the context has something to accumulate into.

If the next brief is already forming while the current one is being signed off, that is the signal. Tell us what the year looks like and we will say whether this is the right shape for it.