Pricing Motion Work: Per-Second, Per-Project, and Why Neither Alone Captures the Real Effort¶
A flat per-second rate is an appealingly simple way to price motion work, and it breaks down quickly in practice, because it treats a simple, repetitive logo animation and a densely animated, fully rigged character sequence as equally priced per unit of runtime - despite requiring wildly different amounts of actual effort. A single flat per-project quote has the opposite problem: it can work reasonably well for a specific, well-understood project type, but it doesn't scale or generalize across genuinely different kinds of work without being recalculated from scratch each time.
Per-Second Pricing Rewards Simple Work and Punishes Complex Work Equally¶
A per-second rate set high enough to fairly compensate for genuinely complex, dense animation work will overprice simple projects relative to their real effort, while a rate set low enough to be competitive for simple work will significantly underprice dense, complex animation. Because complexity per second varies so widely across different motion projects, a single flat per-second number can't accurately price both ends of that range at once, which is exactly why per-second pricing alone tends to produce either lost bids on simple work or unprofitable projects on complex work.
A Complexity Multiplier Applied to a Base Rate Handles This More Accurately¶
Rather than a single flat rate, establishing a base per-second rate for straightforward, simple animation and applying a multiplier for specific complexity factors - character rigging, dense particle or effects work, heavy custom illustration, complicated camera movement - produces a more accurate estimate that scales with the actual effort involved, rather than assuming every second of any project costs the same to produce. This requires assessing complexity honestly during scoping, which takes more upfront effort than a flat rate, but produces quotes that hold up better once actual production begins.
Revision Rounds Need Their Own Explicit Pricing Logic, Not Just Inclusion in the Base Quote¶
As covered elsewhere, revisions on motion work cost meaningfully more than the same conceptual change on static work, and pricing that doesn't separately account for revision cost at different production stages (cheap at the animatic stage, expensive after final animation) risks either underpricing the project if revisions run long, or over-restricting revisions in a way that frustrates a client expecting normal collaborative back-and-forth. A pricing structure that explicitly separates concept development, base production, and revisions gives a more accurate and more defensible total quote than a single undifferentiated number.
Track Actual Time Against Quoted Estimates to Improve Future Pricing¶
The most reliable way to improve pricing accuracy over time is tracking actual hours or effort spent against what was quoted for each completed project, categorized by the same complexity factors used to price it - this builds a real, personal data set for calibrating future complexity multipliers, rather than relying purely on intuition or industry rules of thumb that may not reflect a specific designer's actual workflow and speed.
FAQ¶
Is per-project pricing ever the better choice over a complexity-based rate structure?
For a specific, well-understood, frequently repeated project type (a standard style of social media animation template, for instance), a flat per-project price can work well once it's been calibrated against real completed examples - the complexity-based approach matters most for more varied, less repetitive project types.
How should a freelancer explain complexity-based pricing to a client unfamiliar with motion work?
Breaking down the specific complexity factors driving the quote - rigging, particle effects, camera movement - in plain terms, rather than presenting only a final number, helps a client understand why two seemingly similar-length projects can be priced very differently.
Should pricing account for the designer's own speed and experience level, or just objective project complexity?
Both realistically factor in - a more experienced designer may complete the same complexity of work faster, which is a legitimate basis for a different rate, but the complexity assessment itself should still be based on the actual work involved, not adjusted arbitrarily.