;

Building the Retainer That Scales

Featured Image

Building the Retainer That Scales — Part Two: From Argument to Architecture

Article One set out the case: the agency retainer, contrary to rumour, remains very much alive, though the rationale for its charges has quietly expired. The once-sacrosanct link between time spent and value delivered has all but vanished. Artificial intelligence is steadily squeezing the middle of the delivery chain, that familiar territory where most retainer hours were traditionally consumed. Today, genuine expertise is found not in the routine, but at the very edges of the engagement.

Knowing what's wrong is useful. Knowing what to build instead is the work. This is Part Two.

Most efforts to 'modernise' the retainer fall into a familiar trap. The pricing model is shuffled—hourly rates give way to day rates, day rates to monthly bundles, and so on to value-based fees—yet the substance of the engagement remains curiously untouched. The invoice may look different, but the underlying structure is left resolutely intact.

The outcome is a retainer that resembles its predecessor, merely adorned with new figures. The client remains uncertain about what, precisely, they are receiving. The provider, for their part, is equally unclear about the extent of their obligations. The relationship continues to depend on trust and goodwill, rather than the virtues of clarity and transparency.

Redesigning the retainer isn't a pricing exercise. It's a structural one. And the structure it needs already exists — not in a commercial template, but in a delivery framework built for exactly this kind of complexity.

The DaS™ Framework organises design delivery into five stages that can each operate autonomously, with outputs clear enough for any party to step in, make an informed decision, and move forward. Those five stages — Proposition Shaping, Design Shaping, Design Delivery, Product Delivery, and Integration — aren’t a project plan. They’re a map of where decisions live, who owns them, and what the Definition of Ready looks like at each handover point.

This, in essence, is the architecture a reimagined retainer requires.

The traditional retainer operated without a map. Work would arrive as a brief, traverse the provider’s internal machinery, and eventually reappear as a deliverable. The client’s vantage point was restricted to the bookends of the process. The intervening journey—how decisions were reached, what was validated, what was postponed—remained largely shrouded from view. Such opacity was tolerable when the client relied wholly on the provider. It becomes unsustainable, however, when the client is able to undertake part of the work themselves and must discern precisely where their remit ends and the provider’s begins.

The DaS™ Canvas makes that boundary visible. As a diagnostic tool, its purpose is to help ask better questions, surface hidden gaps, and understand what must change for design to scale effectively. Applied to a client engagement, those questions become commercial ones: where are decisions being made without sufficient information? Where does the client's self-service capability create risk rather than value? Where is the provider's involvement genuinely irreplaceable — and where is it habit rather than necessity?

Answering those questions honestly produces something more durable than a retainer built on goodwill: a shared map of what each party owns, and why.

A retainer grounded in the DaS™ Framework organises the engagement into three distinct zones of responsibility, each aligned with a particular phase of the delivery sequence.

Zone One:

Proposition and Design Shaping — the provider owns this entirely. This is the front boundary. Proposition Shaping establishes what is being built, why it matters, and what success looks like — documented in a Project Identification Document that every discipline has agreed to. Design Shaping explores possibilities, validates assumptions, and pressure-tests the brief before a single component is built. In a client self-service model, skipping these stages is the most common failure point. The client who builds their own website with AI assistance and skips proposition shaping ends up with a fast, coherent-looking product that doesn't solve the right problem. The provider's value here is non-negotiable — and the retainer should reflect that explicitly.

Zone Two:

Design, Delivery, and Product Delivery—shared territory, governed by clear handover criteria. Here, the Definition of Ready assumes the role of a commercial instrument. Design Delivery converts shaped propositions into tokenised, reusable components—specifications, interaction notes, acceptance criteria—sufficiently detailed for engineering to proceed without ambiguity. Where the client is equipped to manage early-stage execution themselves—layouts, prototypes, initial builds—this phase shifts from creation to validation and integration. The provider’s task is to confirm that the client’s output satisfies the Definition of Ready before advancing. This represents a fundamentally different engagement: leaner in hours, greater in accountability, and markedly more difficult to imitate.

Zone Three:

Show and Tell and Integration—the provider leads, the client participates. This marks the back boundary. Show and Tell, often the most neglected step in the DaS™ Framework, has been shown to reduce additional feedback by 35% and pre-release refactoring by 62%. Within a retainer, it is the juncture at which the provider demonstrates system coherence to the client—not as a mere presentation, but as a structured validation that all components, regardless of origin, function as a unified product. Integration then brings all deployments together into a stable, accessible, and compliant release. Here reside accessibility, performance, security, and governance—the very domains where client self-service most frequently falters.

The Retainer That Scales.

"This sounds more complex than a standard retainer."

In truth, it is more explicit, not more complicated. The supposed simplicity of the standard retainer was always something of a mirage: it concealed complexity within the provider’s process, safely out of the client’s sight. Rendering the structure visible does not add overhead; it is precisely what enables the client to place trust in the agreement itself, rather than relying solely on the relationship.

"Clients won't engage with a framework—they simply want the work completed."

The framework is not intended for the client’s instruction. Rather, it serves as the provider’s architecture underpinning the agreement. What the client perceives is clarity: here is our domain, here is yours, and here is what constitutes readiness at each juncture. This is not a methodology; it is a professional standard. Clients respond to it because it mirrors the thinking of well-run organisations.

"Our engagements do not proceed in a linear fashion."

Nor does the DaS™ Framework. Each pillar is capable of operating independently; the sequence serves as a map, not a prescription. One client, immersed in product delivery, may engage the retainer solely at the Integration stage, with the provider’s involvement confined to the back boundary. Another may require only Proposition Shaping, self-serving through to deployment before returning for Show and Tell validation. The Framework accommodates both scenarios, rendering the scope of each engagement sufficiently transparent to permit honest pricing.

The retainer that endures is the one founded on structure, not mere relationship. Relationships, after all, are apt to fray under commercial strain; structures persist because they are anchored in the genuine needs of each party. The DaS™ Framework provides this new retainer with its scaffolding: five stages, clear handovers, explicit ownership at every boundary, and a diagnostic tool in the Canvas that ensures the agreement remains honest over time.

This is the essence of the shift from vendor to partner. It is not a matter of friendlier invoices, but of a shared map of the work: who owns what, what is ready, what it entails, and what neither party should attempt in isolation.

The discussion about what is charged for is merely the starting point. The more intriguing question is how the engagement transforms once the structure is properly established—and how a well-maintained design system foundation alters the possibilities for both parties. That is the ground Part Three will explore. Follow the series at designatscale.co.

Design at Scale™ Your Story Matters

Happy scaling through design!

Hey, I’m Jiri Mocicka.
London-based Product Design Director, Trusted Advisor and Author of Design at Scale™. The method that empowers individuals to shape the future organisation through design.
If you have a question, join our Community and reach out to like-minded individuals who scale design propositions. An online Academy can help you to define teams of 01, 10, and 100, and 1% supported by Grid Magazine and Supply section, where we bring more insights weekly on how to become a design leader in your Agentic Organisation

Author's Name

AVATAR

inResearch

32

inWriting

65

Released

240
EMT

Related.

Featured Image
A little over a year ago, we delivered a basic tokenised design system for a client’s retail operation. Last week, he rang me up …
March 19, 2026
 · 
4 min read
Featured Image
Empathy as Infrastructure: The Internal User Experience of Scaled Systems The ultimate metric of any enterprise system is a deceptively simple question: Does it …
February 16, 2026
 · 
4 min read
Featured Image
The code that stands still does not reflect your agentic systems. Over the past five years, more than a thousand agentic systems have found …
February 10, 2026
 · 
7 min read
Featured Image
Unbiased Scale: Driving Corporate Alignment Through Systemic Decision-Making In a large enterprise environment, product design decisions frequently devolve into a battle of subjective opinions. …
February 9, 2026
 · 
3 min read
Featured Image
AI Design Tools Have Arrived — But Is Your Practice Ready? AI design tools are now capable of transforming a solitary prompt into a …
February 3, 2026
 · 
7 min read
Featured Image
The Retainer Is Not Dead — What Should You Do Instead? The agency retainer was one of the most elegant commercial inventions of the …
March 17, 2026
 · 
6 min read
Featured Image
In our digitally mediated age, user interface design is no longer a mere decorative advantage of commerce. It has become the very engine room …
January 20, 2026
 · 
5 min read
Featured Image
If Ford built the rhythm of production. Toyota taught us to improve it. And Baťa gave it purpose. Then along came digital and transformed …
March 19, 2025
 · 
4 min read
Featured Image
The twentieth century didn’t just change what we made. Instead, it changed how we worked together. When someone says, “Let’s throw some people at …
March 12, 2025
 · 
5 min read

GRID Magazine

Explore OUR 
Articles

Every week we bring set of stories reflecting on communication, operation and technology.

Newsletter

Subscribe.

We share our 20 years of experience in creating, managing and scaling products and services that allow individuals to shape organisations through design.

Design at Scale™

LINE_MAGENTA_050_301

Categories

LINE_MAGENTA_050_301

Data

LINE_MAGENTA_050_301

Share

Internal

Collaborate

Resources

IBM PlexSan
Regular
Charcoal

Design at Scale™ is defined by three models, which form the Method. Each model operates in a different part of the business and collects and informs parties on design and engineering decisions that have a direct impact on the delivery.

All brands and trademarks presented on the Design at Scale™ website are owned by their relevant companies or agencies. The projects represent collaborations between designers, developers and product owners. Do not copy or publish any of the projects shown here without written approval from Design at Scale™ (alternatively GIVE™, 9V™) and/or relevant companies and agencies.

SOC_Twitter
SON_LinkedIn
SON_Instagram
SOC_-Medium
View