In immersive and interactive projects, work rarely exists as a single phase with a clear endpoint. Early on, there is discovery, prototyping, and technical validation. During production, requirements evolve as systems take shape. After launch, work continues through maintenance, updates, and long-term evolution. Most engagement models assume a fixed delivery moment, but this structure doesn’t always fit this kind of work. Retainers offer a more flexible alternative.
Retainers are often treated as post-launch agreements (support contracts), but they can span the entire project lifecycle. When introduced early, they support strategy and prototyping; during production, they enable iteration; and after launch, they sustain maintenance and evolution.
This reframes retainers as a continuous structure that shapes how a system evolves, rather than a post-project add-on.
Three Types of Retainers
Most retainers fall into three overlapping categories defined by what is being purchased: access, capacity, or outcomes.
1) Availability-Based
The client is paying for access, priority, or responsiveness rather than defined output.
- Reserved Availability retainers
Ensure you are available when needed to provide priority access and responsiveness. Value is tied to certainty rather than deliverables. - On-Call retainers
Used in live or high-risk environments where downtime matters. Functions as operational insurance with defined response times, coverage windows, and escalation paths.
2) Time-Based
The client is purchasing a defined amount of working capacity.
- Bucket of Hours retainers
A fixed allocation of time for updates, fixes, support, and iterative improvements. Reduces friction around small, recurring requests. - Embedded / Fractional retainers
You operate as part of the client team, contributing to planning, prototyping, and ongoing direction. This is often a substitute for full-time expertise without hiring overhead.
3) Value-Based
The client is paying for outcomes rather than time or access.
- Outcome-Based retainers
Compensation aligns with measurable results such as performance, stability, or feature delivery. Requires clear metrics and enough control over the system to meaningfully affect those outcomes. - Maintenance & Monitoring retainers
Focused on system health and preventing failure. Success is often invisible when things work correctly, but the value is ongoing stabilization and early intervention. - Content & Iteration retainers
Ongoing updates, seasonal changes, interaction tuning, and design iteration to keep experiences evolving and effective over time. - R&D / Exploration retainers
Funds experimentation and prototyping without production pressure. Enables rapid testing of new interaction models and technologies.
Though these categories and subcategories each have their specific use-cases, the strongest retainer relationships often combine elements from multiple categories. For instance, I may use a time-based approach, where I’m embedded with the team as they ramp up to an event, but during the event, I’m on call, so the main team can be slim while still having backup if needed.
Defining What’s Included & Managing Scope
Most retainer issues come from ambiguity rather than pricing. Clear definitions are essential:
- Consultation and strategic input
- Project management and coordination
- Production and feature development
- Delivery of assets or software
- Technical support and maintenance
Equally important is defining what is not included, especially as experiential systems naturally expand over time.
Operational expectations should also be defined:
- Response times
- Availability windows
- Turnaround for requests
- Approval processes
Without this clarity, urgency-based assumptions replace agreed structure. In some cases, priority levels (e.g. P0–P4) or pricing for rush, after-hours, or weekend work help maintain sustainability.
Clear structure is also needed for scope evolution:
- What qualifies as in-scope work
- What triggers a change order
- Approval requirements
- Tracking methods
- Review cadence
If a request falls outside the original intent, it can be treated as a separate scope, trigger a retainer adjustment as a change order, or be covered by the current retainer agreed to by both parties. It’s often the case that retainers can also save time rather than create a new scope of work. Retainers allow for a lot of flexibility but depend on continuous alignment between expectations and execution.
Get Our 7 Core TouchDesigner Templates, FREE
We’re making our 7 core project file templates available – for free.
These templates shed light into the most useful and sometimes obtuse features of TouchDesigner.
They’re designed to be immediately applicable for the complete TouchDesigner beginner, while also providing inspiration for the advanced user.
Handling Unused Time & Planning the Ramp-Off
Every retainer needs clear boundaries for both unused capacity during the engagement and the eventual transition out of it. During the engagement, unused time should be governed by a defined policy.
Common approaches include:
- Use-it-or-lose-it cycles (monthly or quarterly resets)
- Limited rollover into the next period
- No formal tracking for availability-based retainers
There is no universal model, but there must be a clear one. Unused time is rarely returned directly and is often better converted into adjacent value, such as refinements, documentation, cleanup, or system improvements. If usage consistently exceeds expectations, it should be flagged early to avoid unplanned overages.
Equally important is planning the end of the engagement. Every retainer should include an exit strategy, which may include:
- Notice periods
- Knowledge transfer requirements
- Final deliverables
- Documentation handoff
A structured ramp-off protects both sides and preserves continuity. In many cases, a well-managed exit leads naturally to future re-engagement as the system evolves.
Does the Client Actually Need One?
A well-structured retainer sets a strong foundation for the work, extends the life of a project, protects quality, and gives clients ongoing access to the expertise that shaped the work. It turns a one-time engagement into a continuous system of support rather than a fixed delivery moment. The challenge is designing a model that supports that continuity without creating confusion around scope, value, or responsibility. But not every project benefits from a retainer. Retainers are most appropriate when:
- Systems are technically complex
- The experience requires ongoing updates or iteration
- Internal teams lack the necessary specialized expertise
- Fast response times are important
- Future requirements are expected to evolve
If none of these conditions are present, a retainer can introduce unnecessary overhead rather than value. That said, retainers also serve a structural purpose for service-based practices. They create continuity between larger project engagements and help stabilize workload across time.
Final Thoughts
The biggest shift with retainers is that you are no longer being hired only to deliver a product, but to help create a foundation for growth and stay with it as it evolves. In experiential work, where technology, content, and user behavior are constantly shifting, that ongoing relationship is often where the real value lives. It becomes less about a single output and more about continuously refining the system and expanding its capabilities over time.
In the best cases, this becomes a deeper partnership where the work exceeds the sum of its parts, and the knowledge gained becomes part of the service itself: continuing to evolve over time.
