Hidden Costs in Game Art Outsourcing: What a Quote Usually Leaves Out
-
Written byDenys Zadoienyi
-
Updated on25.08.2026
-
Time to read11 min
“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”
A quote that leaves out scope isn’t dishonest. Every vendor prices a defined deliverable, and pricing an undefined one is not actually possible — nobody can quote “unlimited revisions” or “every platform you might eventually target” without either padding the number so heavily it stops being competitive, or guessing wrong in a way that loses money on the engagement. The exclusion itself isn’t the problem.
The problem is when the client doesn’t know the exclusion exists until it’s already a bill. A number that looked competitive during vendor comparison turns out to have been competitive because it was scoped narrower than a competing quote that included more — and that difference doesn’t show up until months into production, when the schedule has no slack left to absorb it.
This isn’t about why two quotes for the same brief land on different numbers in the first place — pricing model, ambiguity handling, and team composition all play into that, and our breakdown of what actually drives a game art outsourcing quote covers that analytical side in depth. This is narrower and more actionable: four specific categories worth checking, in writing, before you sign anything — whichever quote you’re comparing them against.
In our experience running outsourced art production across mid-core and AAA titles, four categories of work sit outside the initial quote more often than clients expect, for reasons that are usually legitimate on the vendor’s side. Knowing what they are — and asking about them before signing, not after — is the difference between a quote you can actually plan a budget around and one that becomes a moving target.
“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”
1. Revisions Beyond the Included Rounds
What’s typically excluded. A quote prices a bounded revision allowance as part of the deliverable — how many rounds, and what counts against them, varies by asset type and production stage rather than following one fixed number. Anything past that allowance is additional work, billed separately, at a rate that may or may not have been part of the conversation when you were comparing vendors on price.
Why it’s excluded, legitimately. A vendor can’t price unlimited revision into a fixed quote and stay competitive, because revision volume is driven largely by something outside the vendor’s control: how specific the brief was to begin with. Pricing for worst-case revision load on every asset would inflate every quote — including the ones where the client’s brief is tight enough that most assets clear in one or two passes. Bounding the included rounds is how a vendor keeps the number honest for clients who come in prepared, rather than making every client subsidize the ones who don’t.
What it costs when it surfaces. If the overage rate wasn’t defined before signing, the client is left negotiating it mid-production, at a point where switching vendors or rebidding the work is significantly more expensive than it would have been at quote stage. That’s a gap in the contract, not a default way vendors operate — the rate can and should be pre-agreed at quote stage, the same way the included allowance is.
What to ask before signing. How many rounds are included per milestone stage, and is that number the same across every asset category or does it vary by complexity? What’s the defined rate for a round beyond that count, stated as a number now rather than negotiated later? And — one of the strongest levers actually inside your control — how specific is the brief you’re handing over, since brief quality is one of the biggest client-controlled drivers of how often you need rounds beyond what’s included, alongside factors like vendor capability and how much art direction shifts mid-production. If your brief still reads more like a mood board than a technical specification, tightening it before you request quotes will do more to control this cost than any contract clause — our breakdown of what a production-grade brief needs to specify covers exactly where generic briefs leave gaps that revision rounds end up paying for.
2. Platform and Engine Adaptation
What’s typically excluded. A quote is priced against one target: one engine, one platform tier, one performance budget. Adapting the same asset for a second platform — a mobile version of a PC asset, a lower LOD tier for a last-gen console SKU, rebuilding or adapting the material and shader setup for a different engine — is treated as separate scope, not an automatic extension of the original delivery.
Why it’s excluded, legitimately. Platform adaptation is genuinely different production work, not a checkbox. A character built for a PC/console performance budget doesn’t just “export smaller” for mobile — depending on how the original master asset was built, it may require a different topology decimation pass, a different texture resolution and compression strategy, and sometimes a rebuilt material setup if the target engine handles shading differently. Bundling that work into every quote by default would inflate pricing for every client who only needs one platform, to subsidize the minority who need several.
What it costs when it surfaces. Multi-platform ambitions frequently firm up after art production has already started — a PC-first title gets a console port greenlit, or a mobile version gets added to the roadmap mid-development. At that point, the vendor treats the adapted assets as new scope, priced without the leverage of a competitive quote comparison, because there’s no competing bid on the table anymore.
What to ask before signing. Is a second platform a realistic possibility within this project’s timeline, even if it isn’t committed yet? If so, get an adaptation rate priced as an optional line item now, while there’s still competitive pressure on the number, rather than waiting until it’s a forced negotiation with a vendor who already has your first-platform assets and your production momentum. For a closer look at what actually changes technically between platform targets — the parameters a spec needs to cover so adaptation doesn’t turn into rework — our guide to the asset import pipeline across engines walks through the conventions that differ from one target to the next.
3. Source File Preparation and Delivery
What’s typically excluded. Source-file delivery isn’t standardized across game art outsourcing engagements — some vendors include DCC and texture source files as part of the base deliverable, while others scope them separately. What should never be assumed is that IP assignment automatically defines which editable working files actually get handed over — the layered PSD, the unbaked high-poly sculpt, the uncollapsed rig are a separate delivery question from who owns the finished work.
Why it’s excluded, legitimately. Preparing a source file for handoff is real additional work — organizing layers, applying naming conventions, and documenting a file well enough that someone outside the original team can actually pick it up, none of which a flattened export needs. Pricing that work into every quote by default would charge every client for a capability that not every engagement needs — inclusion varies by vendor, asset type, and how the contract is structured, which is exactly why it belongs in the SOW as a named term rather than an assumption on either side.
What it costs when it surfaces. The gap shows up months after delivery, not during production — a sequel needs a variant of an existing character, a different team needs to adjust a prop, or the studio switches vendors and the new team needs to pick up where the old one left off. Without the source file, the options are paying for it retroactively (often at a premium, since there’s no competitive quote pressure at that point) or rebuilding the asset from scratch.
What to ask before signing. Which specific source files are included in the deliverable, in what format, whether any proprietary tools or plugins are required to open them, and whether that’s stated in writing before work begins — not implied, not assumed. This is exactly the kind of term that belongs in the procurement documentation rather than a verbal understanding from the kickoff call; our guide to structuring RFP and SOW terms for game art outsourcing covers how to write source-file inclusion into the contract as an explicit deliverable rather than an assumption either side might be wrong about.
The same distinction shows up outside 3D production, too — a concept art quote can price a finished flattened image or a working layered file as two different deliverables, and our breakdown of what a complete concept art quote should state covers how that specific gap plays out for concept work.
4. Post-Delivery Technical Support
What’s typically excluded. “Delivery” in most engagements means the asset passes milestone acceptance and the engagement moves to the next batch — or closes entirely. Integration issues that surface after that point, once your internal engineers are actually working the asset into a live build, commonly fall outside the original scope unless a support window was explicitly negotiated.
Why it’s excluded, legitimately. A vendor can’t price open-ended after-delivery liability into a fixed quote any more than they can price unlimited revisions. Once a batch is accepted and the vendor’s team has moved capacity to the next client or the next milestone, reopening that work has a real cost — reassigning an artist, rebuilding context on an asset they haven’t touched in weeks. Without a defined window, that cost has no natural boundary, and no vendor can quote a number for something with no boundary.
There’s an important distinction underneath this, and it’s worth naming explicitly. If an asset doesn’t actually conform to the specification it was accepted against — the wrong naming convention, an import setting that contradicts what was agreed — that’s a non-conformance issue rather than automatically new support scope, and the SOW should state how such defects are remedied after acceptance. What a support window is actually for is the other category: issues that appear because something changed after acceptance — an engine version update, a shifted target platform, a master material the client revised — where the asset was correct against the spec at the time, and the spec is what moved.
What it costs when it surfaces. The issue that surfaces after acceptance is often technically small — a naming mismatch, an import setting that needs adjustment, a material that reads slightly differently once it’s actually lit in your build rather than the vendor’s render. Whether it’s a covered correction or new paid scope depends on whether the delivered asset failed the agreed specification or the production environment changed after acceptance — and without that line drawn in the contract in advance, resolving even a small issue means either a mini-negotiation with a vendor whose team has moved on, or your internal team absorbing the fix at a higher cost than defining the boundary up front would have been.
What to ask before signing. Is there a defined post-acceptance support window, stated as a specific duration rather than left open-ended? Support windows vary substantially by engagement and asset volume, so there’s no benchmark number worth anchoring to — what matters is that the contract states the duration, the response time, which defect types are covered, and where the line sits between correcting a non-conforming deliverable and pricing new post-acceptance scope. Our 8-week vendor onboarding protocol covers how a committed response SLA works in practice during active production — the same governance logic applies to defining what happens after a milestone closes.
“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”
A Quick Way to Check Your Quote Before You Sign
Before comparing quotes across vendors, or before signing the one you’ve settled on, these four questions map directly to the categories above:
- How many revision rounds are included per asset, and what’s the defined rate beyond that?
- Is platform or engine adaptation priced as an optional line item, even if you’re not committing to it yet?
- Which specific source files are included, in what format, stated in writing?
- Is there a defined post-acceptance support window, and what does it cover?
A quote that can’t answer these clearly isn’t necessarily a bad quote — it might just be an incomplete conversation. These four categories sit alongside the broader set of factors that move a quote’s baseline number in the first place; our wider breakdown of game art outsourcing cost drivers covers how asset complexity, fidelity tier, and engagement model affect the number before these four exclusions even enter the picture. None of these four categories being excluded from a quote is a red flag by itself. The risk is discovering the exclusion after signing, when there’s no competing number left to compare the answer against.
