Scoping Motion Work by Deliverable Length and Revision Rounds, Not Just "a Video"¶

A quote for "a 30-second video" sounds like a specific, bounded deliverable, but it hides an enormous range of possible effort. Thirty seconds of a simple logo animation and thirty seconds of dense, character-driven, fully rigged animation both fit the same runtime description while requiring wildly different amounts of work - which means runtime alone is a poor basis for a scope or a quote, even though it's the detail clients most naturally lead with.

Complexity Per Second Is the Real Cost Driver, Not Total Runtime¶

The actual effort in motion work scales with how much is happening in each second - number of distinct elements animating simultaneously, complexity of the movement, how much custom illustration or rigging is required - far more than it scales with total duration. A ten-second sequence with dense, layered animation can take longer to produce than a sixty-second sequence built mostly from simple, repeated motion patterns. Scoping and pricing purely by runtime, without accounting for this, systematically underprices dense, complex work and overprices simple, repetitive work.

Revision Rounds on Motion Work Cost More Than the Same Rounds on Static Work¶

A revision on a static design typically means adjusting a layout or color and re-rendering an image, a relatively fast cycle. A revision on motion work - adjusting timing, re-animating a sequence, re-rendering - often takes meaningfully longer per round, especially as render times scale with complexity and length. A scope that includes "two rounds of revisions" without specifying what counts as a revision (a small timing tweak versus a full re-animation of a sequence) leaves this cost ambiguous in exactly the place where it compounds fastest.

Define What "Locked" Means at Each Stage of Production¶

Motion projects typically move through distinct stages - storyboard or script approval, style frame approval, animatic approval, final animation - and defining what's considered locked at each stage prevents a late-stage change from silently becoming full rework. A client requesting a different visual style after style frames are approved but before final animation is a meaningfully smaller change than the same request made after final animation is already complete, and a scope that treats every revision at every stage identically doesn't reflect that real difference in cost.

Separate Concept Development From Production Explicitly¶

Storyboarding, scriptwriting, and style frame development are genuinely distinct work from the animation production itself, and treating the entire project as a single undifferentiated line item makes it hard to have a clear conversation later about where in the process a change request actually falls. Scoping these as separate phases, each with their own defined deliverable and revision allowance, gives both sides a clearer reference point for what's included and what constitutes additional work outside the original scope.

FAQ¶

Is it possible to give a client an accurate quote before a full script or storyboard exists?
Usually only a rough estimate at that stage - a firmer quote is more realistic once a script or storyboard is at least roughly defined, since that's the point at which the actual complexity and length of the work becomes clear enough to price accurately.

How should revision rounds on the animatic stage be counted separately from final animation revisions?
Treating them as genuinely separate allowances - since an animatic revision is far cheaper than a final animation revision - keeps the incentive structure aligned: clients are encouraged to resolve pacing and structure at the cheaper, earlier stage rather than deferring those decisions to the more expensive final stage.

What's the most common scoping mistake in motion design work?
Quoting primarily off runtime without a clear complexity assessment - this is the single most common reason a motion project ends up costing significantly more effort than what was actually priced, since two projects with identical runtimes can require dramatically different amounts of work.