What should a growth-driven design contract and ongoing retainer include?

A growth-driven design agreement has two linked parts: a project contract for the strategy phase and the launchpad build, and an ongoing retainer for continuous improvement, each scoped and priced separately [8][5]. Growth-driven design runs in three phases, strategy, launchpad, and continuous improvement, and a well-built agreement mirrors that structure rather than treating the whole engagement as one fixed deliverable [8]. The project half covers the research, the documented strategy, and the first live version of the site; the retainer half covers the recurring sprints that keep improving it against real visitor data after launch [3]. Reading the two as one lump is the most common way these agreements go wrong, because it hides where the recurring cost lives and what it is supposed to produce.

The retainer is where growth-driven design departs from a traditional redesign, since the site keeps changing after launch and the contract has to account for recurring, prioritized work instead of a finished handoff [3][2]. That is also where most of the terms that protect both sides live. The sections below cover the six components that belong in a complete agreement: the scope and deliverables, the retainer structure and monthly hours with benchmark pricing, the focus metric and reporting cadence, ownership of the site and its data, the exit and pause terms, and the protections that keep both sides honest. Each one is a place a vague contract tends to fail, and each is straightforward to pin down once you know to ask.

The contract should enumerate the deliverables of each phase, the way a standard web development agreement lists scope, deliverables, timeline, pricing, and the success metrics the work is measured against [7]. Growth-driven design has three phases, and each produces a different kind of deliverable, so naming them separately keeps the engagement from drifting into open-ended billing.

For the strategy phase, the deliverables are the tangible research outputs: the user and buyer research, the documented assumptions about what will move the numbers, and the prioritized wishlist that becomes the roadmap [5]. For the launchpad, the deliverable is a live site covering the pages that carry the buyer's decision, commonly three to eight of them rather than a full page-by-page rebuild [5]. For continuous improvement, there is no single fixed artifact; the deliverable is a recurring cadence of sprints, each shipping changes and returning a report on how they performed against the metric in focus [3].

Writing the deliverables down this precisely does two things. It ties each payment to a defined output instead of to hours spent, and it gives both sides a shared definition of done for every phase, which is what a success-metrics clause in a standard agreement is meant to provide [7]. A contract that lists "ongoing optimization" with no named outputs is the version that later produces disputes about what the retainer was supposed to buy.

Every sprint in the retainer should open with one named focus metric it is meant to move, and the agreement should require the team to report against that metric each cycle [3]. The focus metric is the number both sides use to judge whether the engagement is working, so choosing it is the most consequential decision in each sprint. A cycle aimed at improving everything improves nothing anyone can measure, while a cycle aimed at demo requests from the pricing page produces a result that can be judged and learned from [3].

The reporting cadence follows the sprint cadence. The core growth-driven design model runs continuous improvement in time-boxed sprints that move through plan, build, learn, and transfer, and the report belongs at the end of each one [3]. IMPACT's variant runs a monthly cycle, and either interval works as long as it is fixed and the report shows before-and-after numbers on the focus metric rather than a list of activity [2][3]. An activity log tells the client the agency was busy; a focus-metric report tells the client whether the money moved the number it was spent to move.

The transfer step is the part teams skip and should not. It hands what the sprint learned to marketing, sales, and service, so the value of the retainer reaches past the website, and those learnings become inputs to the next planning session [3]. Building that reporting rhythm into the contract is also what lets renewal rest on evidence instead of sentiment.

The agreement should state plainly that the client owns the finished site, its content, and its analytics and customer data, and that those assets are handed over in a usable form if the engagement ends [7]. A standard web development agreement already enumerates the deliverables and terms of the work [7]; a growth-driven design contract should extend that to name who owns each asset once it ships, because the retainer keeps producing new assets every month.

Four things are worth naming specifically. The codebase and content management assets should be portable, not locked inside a proprietary system the client cannot take elsewhere. The content and design source files, including the Figma files behind the pages, belong to the client. The analytics history and the experiment records matter as much as the site itself, because the next team needs that history to keep improving rather than starting the learning over. And the third-party accounts, the HubSpot portal, the domain, and the analytics properties, should sit in the client's own name rather than the agency's, so access never depends on the relationship staying intact.

Naming ownership this way removes the most common source of friction when an engagement ends. When the site, the data, and the accounts already belong to the client on paper, there is nothing to negotiate at exit and no work held back against a final invoice.

The agreement should set a minimum term, a notice period for ending it, and a defined way to pause the retainer without losing the work in progress [1][2]. Each of the three prevents a specific failure mode, so all three belong in writing.

A minimum term protects the model from being judged too early. The common floor is six months, because continuous improvement needs several cycles before the compounding shows up, and an engagement shorter than that stops being continuous improvement and becomes a rapid-launch project measured on a single launch instead [1]. A notice period, commonly 30 days, protects both sides at the other end: it lets either party end the engagement without being trapped, while giving the final sprint enough runway to close cleanly and hand off its report and data.

Pause terms are the piece most contracts miss. A defined way to suspend billing for a set window, for a budget freeze or a seasonal slowdown, while retaining the roadmap, the analytics, and the prioritized queue, lets the work resume later without paying to rebuild strategy from scratch. The same flexibility shows up inside an active month: one advantage of the retainer model is that the budget can be reallocated toward whatever the data says matters most that cycle rather than locked to a fixed deliverable [2]. Exit and pause terms written this way are what make a multi-month commitment reasonable to sign in the first place.

A workable agreement protects the client with performance reporting and asset ownership, and protects the agency with a capacity floor and a scope-control rule, so neither side can quietly stop delivering [1][2]. The protections are worth stating individually, because each closes a gap that otherwise gets exploited by drift rather than bad intent.

On the client's side, before-and-after reporting each cycle keeps the retainer accountable to results rather than to activity, and it is the single term most worth insisting on [2]. The budget should be reallocatable within the retainer, so spend follows the data instead of a fixed plan written before any of it existed [2]. Renewal checkpoints should be tied to movement on the focus metric, which turns the renewal conversation into a review of evidence rather than a matter of goodwill [1][3].

On the agency's side, a capacity floor belongs in the agreement, because below roughly 15 hours per month there is not enough room to do meaningful work and outcomes become inconsistent regardless of effort [1]. Scope requests from stakeholders should route through the prioritized wishlist rather than being appended to the active sprint, which keeps a cadence from being derailed by whoever asks loudest [1][3]. Together these terms make the arrangement legible: the client can see the numbers move, and the agency can protect the focus that makes them move.

A growth-driven design retainer is not a maintenance plan. The work is experiment-driven against a focus metric through a plan, build, learn, and transfer cycle, not a ticket queue for content edits and plugin updates [3]. Confusing the two is how a retainer priced for optimization ends up spent on housekeeping.

It is also not unlimited work. The hours or points cap each month, and prioritization decides what ships, which is why the wishlist and the focus metric matter more than the size of the backlog [1]. A retainer is not a guarantee of lift either; results depend on traffic volume, testing discipline, and how honestly the team retires the ideas that lose, so the agreement buys a disciplined process rather than a promised percentage [3]. And a three-month agreement is not a smaller version of the same thing: at that length the engagement becomes a rapid-launch project, and the continuous-improvement value that justifies the retainer never gets the cycles it needs to compound [1]. Knowing what the retainer is not is what keeps a client from underbuying the term or overreading the guarantee.