CGI Costs: What's Actually Behind the Price

The most common misconception in CGI pricing: that the cost is in the software.

It rarely comes as a direct statement. More often it arrives as a question: "Can't a student just do it in Blender?" Or as a remark: "I thought software was affordable these days." Or as a comparison: "I have a quote that's half the price."

The answer to all three is the same. Software is the smallest line item in a CGI estimate — in some projects, literally the smallest. The cost isn't in the tools. It's in the time it takes to produce something that works using those tools. In the planning depth that prevents half of that time from being spent on corrections. In the risk buffer that prevents unforeseen problems from eating through the budget without anyone naming them.

In this article I describe three situations in which this misconception turns into concrete costs — not as theory, but from my own experience. The last one is the most expensive.

The Software Costs Nothing. The Time Costs Everything.

A commercial is to be set against a digitally created background — a CGI environment that places the product in a particular world. The client has done research. He knows that common 3D applications are available for a few hundred euros a year. He has seen tutorials in which private individuals build similar environments in a few hours. He wonders why my quote is so far above that.

It's an understandable question. The answer isn't in the software.

What a CGI environment for a commercial actually costs is made up of several factors, of which software accounts for perhaps five to ten percent. The rest lies in artist time — and artist time isn't cursor-moving time. It's decision-making time. Every texture, every lighting setup, every geometric detail is a decision that has to be made, assessed, and weighed against the overall impression of the shot. This weighing work is what scales — not the tool costs.

Add to that pipeline experience. An environment built in a coherent, documented structure allows corrections to be made in hours. An environment built without structure becomes a risk with every correction — because nobody can predict what a change in one place will trigger in another. The difference between the two isn't visible in the first render. It becomes visible in round three, when something has to change.

And then there's the planning. Before a single piece of geometry is modelled, there are questions that need to be answered: which camera position? Which focal length? What lighting logic should the environment carry? Which elements need to behave physically accurately, which can be simplified? These questions sound like overhead. In reality they are the investment that decides whether the environment convinces on first review or needs three more rounds.

What I say in such conversations: the software is the stove. What the dish costs has nothing to do with the stove price. It depends on what's being cooked, how many people are eating, and how much experience stands in the kitchen. The misconception is human — and I prefer to explain it once explicitly rather than leave it unspoken. Because unspoken, it becomes a problem when the budget was set based on the tool price, and the actual work then has to be cut somewhere.

What's Missing from the Estimate Claims It in Post

The second case is subtler, because it doesn't fail at the price. It fails at what the estimate doesn't contain.

A CGI project is commissioned. The budget is agreed, the timeline is defined, the delivery dates are set. What isn't defined: the number of correction rounds. What isn't assessed: the risk profile of the project. What isn't specified: which asset variants are to be delivered, what counts as 'done', what happens if the brief changes during production.

These gaps are often invisible at the point of commission. They become visible when the project is running.

What I mean by the risk profile of a CGI project: how precise is the brief? Is there a clear visual reference, or is 'dramatic and modern' the guiding principle? How many reviewers will assess the output? How capable of making decisions is the client side? Are there external dependencies — product photos not yet available, packaging designs that might still change, shoot dates that VFX elements depend on?

Each of these questions carries a risk that materialises in artist time if it isn't assessed and priced in advance. A project with an unclear visual reference is a project that needs several style iterations before the direction is established. That isn't incompetence on the artist's part — it's the direct result of missing upfront definition.

In my experience, the risk buffer is absent from most estimates I see that didn't come from me. Not because the vendors forgot it, but because a quote with a buffer looks more expensive on paper than one without. In a competitive process, the quote with the buffer loses. So the buffer disappears.

What happens next: the budget runs out before the result is right. Something has to be cut somewhere. It almost always happens in the finish — in the final detail decisions, the final lighting corrections, the final integration adjustments. Exactly where the shot moves from 'almost done' to 'done'.

When I estimate, the risk buffer is its own line item, which I name and explain explicitly — not as a hidden safety margin, but openly as room for what we don't yet know. That makes the quote more expensive on paper. It makes the project more plannable in execution — because what we don't yet know will be paid for somewhere, whether it appears in the estimate or not.

When the Price Is Right — But Too Late

The third case is the one I have experienced multiple times in my practice. It starts with an enquiry.

A potential client describes their project. I listen, ask questions, estimate. The quote goes out. Then one of two things happens: either the client stops responding — the silence is the answer. Or they respond and say it's too expensive. In both cases, the project goes elsewhere, to a cheaper provider who takes it on at a price my quote hadn't reached.

That is a legitimate decision. The client has a budget, the quote doesn't fit within it, they look for another solution. That is normal business — and I have learned to leave it without bitterness.

What comes after is what occupies me.

A few weeks later — sometimes days, sometimes a month — a message arrives. The client is back. The cheaper provider wasn't able to deliver: technical problems, quality problems, communication problems, sometimes simply being out of their depth. The result isn't usable. The deadline is approaching.

My first question: when does the project have to be finished? The answer is usually "end of the week" or "in ten days." My second question: what is the remaining budget? The answer is usually an amount well below my original quote — because the other provider has already spent the budget.

At this point, I decline.

Not out of spite, and not as a lesson. I decline because the conditions now on the table — little time, little budget, a project in an unknown state whose problems I cannot assess — are the conditions under which I cannot deliver what the project needs. Making a promise under these conditions would be dishonest. It would be what the cheaper provider did.

What concerns me about this situation isn't the individual case. It's the pattern behind it. The original pricing decision — the quote is too expensive, I'll take the cheaper one — produced consequences that ultimately cost considerably more than my quote. The client paid twice: once for the cheaper provider who couldn't deliver. And once for the time pressure, the damaged material, the restart under poor conditions.

I don't say this to defend my price level. I say it because it illustrates the estimating logic of the first two sections in concrete terms: a price too low to estimate soundly saves money at the beginning. It miscalculates at the end.

What a Solid Estimate Actually Buys

Three situations, one underlying structure. The costs arise where they weren't priced in — in the planning depth, the risk buffer, the quality reserve for the final finish. If these items aren't made visible in the estimate, they don't disappear. They turn up later, at a less convenient moment and at a higher price.

My point for clients who are comparing quotes: a cheaper quote isn't the same as a cheaper project. It is often a quote that doesn't account for the same factors — and those factors will be paid for over the course of the project, whether they appear in the quote or not. The question isn't which quote is cheaper. The question is which one is more complete.

What a solid estimate actually buys isn't a guarantee of a perfect result. It buys predictability. It buys a project that has already priced in the things that can go wrong — and that therefore, when something does go wrong, doesn't immediately become an emergency.



The result of an estimate without these items is usually a shot that almost works. That isn't a technical failure. It is the direct result of a budget that was too small for the complete project.