Client Revision Rounds on Motion Work: Why "Just One More Version" Costs More Than in Static Design¶

A client asking for "just one small tweak" on a static layout - adjust this color, move this element - is usually a genuinely small ask, resolved with a quick edit and a re-export. The same phrase applied to motion work frequently isn't small at all, because a change to timing, easing, or an element's motion path often requires re-rendering some or all of the affected sequence, and render time doesn't shrink to match how minor the requested change felt to the person asking for it.

A Small Creative Change Can Require a Disproportionately Large Technical Change¶

Adjusting the timing of one element partway through a sequence can require re-timing everything that follows it to keep the overall rhythm and sync intact, turning what sounds like a single small edit into effectively re-animating a significant portion of the piece. This asymmetry between how small a request sounds and how much actual rework it requires is specific to motion work in a way that doesn't apply the same way to most static design revisions, and it's worth explaining directly to clients who haven't worked in motion before and don't have an intuitive sense of it.

Render Time Adds a Real, Fixed Cost to Every Revision, Regardless of Size¶

Beyond the actual animation adjustment itself, every revision that changes rendered output requires re-rendering, which takes real time independent of how small the underlying creative change was - a tiny timing adjustment and a substantial creative change can require similar re-render time if they both touch the same portion of a complex sequence. This means the cost of "just one more small change" includes a render-time cost that a client, focused only on the creative size of their request, has no visibility into and no natural reason to account for.

Scope Revision Rounds by Stage, Since the Cost of the Same Request Changes Dramatically¶

The exact same requested change - adjusting a specific element's timing - costs very little at the animatic stage, where everything is still rough and cheap to redo, and costs significantly more once final animation is complete and rendered. Making this distinction explicit in the project scope, rather than treating "a revision" as a single undifferentiated concept regardless of production stage, gives both sides a shared, accurate understanding of why the same kind of request has different implications depending on when in the process it comes up.

Explain the Real Cost Difference Directly, Rather Than Just Enforcing a Round Limit¶

Simply pointing to a contractual round limit when a client makes an unscoped request can feel arbitrary and adversarial if they don't understand why motion revisions are more costly than they might expect from other creative work. Briefly explaining the actual mechanism - "this specific change affects the timing of everything after it in the sequence, so it requires re-animating and re-rendering that whole section, not just this one moment" - tends to land better and build more durable client understanding than citing a round limit alone.

FAQ¶

Should motion design contracts define revision rounds differently than static design contracts?
Generally yes - explicitly distinguishing between revisions at the rough (animatic) stage versus revisions after final animation, given how differently they're priced in effort, produces a scope that more accurately reflects the real cost structure of motion work specifically.

How can a designer estimate the real cost of a specific revision request before agreeing to it?
Considering how far downstream in the sequence the requested change's effects would ripple - a change near the very end of a sequence typically has a smaller ripple effect than the same kind of change made near the beginning - gives a reasonably quick, if rough, estimate of the actual scope of rework involved.

Is it reasonable to charge differently for revisions depending on where in the sequence they occur?
It can be a reasonable and transparent way to price revisions more accurately, though it adds some complexity to the pricing structure - the simpler and more common alternative is pricing revisions by production stage (animatic versus final) rather than by exact position within the sequence.