How to Price Game Development Contract Work So You Do Not Undercharge

Three years into freelancing as a game developer, I took a contract to build a combat system prototype for a small studio. We agreed on $4,000 for four weeks of work. The spec was a single page: a bulleted list of attack types, a dodge mechanic, and “basic enemy AI.”

Six weeks later I was still working. “Basic enemy AI” turned into three distinct enemy behavior trees. The dodge mechanic needed invincibility frames, directional rolls, and cancel windows. The studio asked for a hitbox visualization debug tool so their designer could tune the feel. By the time I delivered, I had spent roughly 240 hours on what I originally estimated at 120. My effective rate was about $17 per hour.

That project was the most expensive lesson I have learned about pricing game development contract work. The problem was not my skill level or my speed. The problem was that I had no system for turning a vague spec into a defensible price, no framework for handling changes when the scope shifted, and no data from past projects to calibrate my estimates against.

Over the past five years, I have rebuilt how I price every contract. These days, I rarely finish a project below my target rate. Here is what changed.

Setting Rates for Art, Audio, Programming, and Design Tasks

Game development contract work is not one thing. A pixel art character sheet, a dynamic soundtrack, a networked multiplayer system, and a level design pass are completely different types of work with different cost structures, different risk profiles, and different market rates. Pricing them all the same way is a fast path to undercharging on some and overcharging on others.

How rates differ by discipline

Here is how I think about rate ranges for the most common freelance game dev disciplines. These are based on what I have seen across indie and mid-tier studio contracts in the US market over the past several years:

• Programming. Gameplay programming, tools development, engine work, networking, and systems programming typically command $50 to $150 per hour depending on specialization. Console porting, shader programming, and multiplayer networking sit at the higher end because fewer people do them and the technical risk is significant. General gameplay programming in Unity or Godot sits closer to the middle. If you are doing something that requires deep engine knowledge or platform-specific expertise (Switch porting, PS5 certification prep), charge accordingly. That knowledge took years to build.
• Art. 2D artists, 3D modelers, animators, and concept artists often price per deliverable rather than per hour. A character sprite sheet might run $200 to $1,500 depending on complexity and animation frame count. A full 3D character model with rigging and basic animations can range from $1,000 to $5,000 or more. Environment art, tilesets, and UI design each have their own benchmarks. The key distinction: art pricing is usually anchored to the asset, not the clock.
• Audio. Composers and sound designers typically price per minute of finished audio (for music) or per asset batch (for sound effects). Original music ranges from $200 to $1,000 per finished minute depending on complexity and instrumentation. Sound effect packages are often quoted as bundles: a set of 30 to 50 gameplay sound effects might run $1,500 to $4,000. Voice direction and implementation work is usually hourly, in the $40 to $100 range.
• Design. Game design, level design, and narrative design contracts are harder to benchmark because the deliverables vary so widely. A level design pass on existing geometry might be a few days of work. A full game design document with systems design, economy balancing, and progression curves could be a multi-month engagement. Design rates tend to range from $40 to $120 per hour, with systems designers and technical designers at the higher end.

Figuring out where you sit in these ranges

The ranges above are wide for a reason. Where you land depends on a few things that are specific to you:

• Shipped titles. If you can point to games you worked on that people have played, you can charge more. A credit on a game that sold well or got critical attention is worth more than any portfolio piece. Studios pay a premium for the confidence that comes from knowing you have actually shipped something.
• Specialization depth. A generalist gameplay programmer in Unity and a specialist in Unreal multiplayer networking are not in the same rate bracket. The specialist solves problems the generalist cannot, and that scarcity drives the rate up. If you have deep expertise in a specific area, price for it.
• Turnaround reliability. Studios outsourcing work care about predictability almost as much as quality. If you have a track record of delivering on time and communicating proactively when things slip, that reputation has real value. You can charge more because the studio is paying for lower risk.

The cost-of-doing-business factor

One mistake I see newer freelance game devs make is pricing their time as if the hourly rate is pure income. It is not. You need to cover software licenses (Unity Pro, Substance, Houdini, audio middleware), hardware costs (especially if you maintain multiple target platform dev kits), self-employment taxes, health insurance, and the unbillable hours you spend on project management, invoicing, and finding the next gig.

A rough rule of thumb: your billable rate needs to be about 1.5 to 2 times what you would accept as a salaried hourly equivalent. If a full-time engine programmer role pays $120,000 a year (roughly $58 per hour), your freelance rate should be in the $85 to $115 range to match that take-home after overhead. Anything less and you are subsidizing the studio’s project with your own savings.

Quoting Project-Based vs Hourly: Choosing the Right Model

This is the question that generates the most debate in game dev freelancing circles, and the answer is not one-size-fits-all. Both models work, but each one fits certain types of contracts, and using the wrong model for the situation is where undercharging starts.

When project-based pricing works

Project-based (fixed-price) quoting works best when you can see the entire scope before you start:

• The deliverable is concrete and well-defined. “Create 12 character sprites, each with 8-frame walk, attack, and death animations at 64x64 resolution” is specific enough to price accurately. You know the asset count, the complexity per asset, and the format. A fixed price protects your margin because you can estimate with confidence.
• You have done this exact type of work before. If you have built three inventory systems and a studio needs a fourth, you know where the time goes. Your estimate is grounded in experience, not guesswork. Fixed pricing rewards that experience because you can deliver faster than your estimate implies and keep the margin.
• The studio has a locked budget. Indie studios working off a grant, a Kickstarter budget, or a publisher advance often need to know the exact cost upfront. A project-based quote gives them that certainty.

When I quote project-based, I add a 20% to 30% margin on top of my honest time estimate. That margin is not padding. It is the price of absorbing the unknowns that exist in every game development task. An animation pipeline that chokes on your export settings. A shader that behaves differently on the target GPU than in the editor. A third-party plugin that updates mid-project and breaks your integration. These things happen.

When hourly pricing works

Hourly billing is the right model when the scope is fluid or genuinely unknown:

• The project is still in pre-production. A studio wants you to prototype three different combat systems so the design team can pick one. The scope is deliberately exploratory. Fixed-pricing this means either padding the quote so heavily that you price yourself out, or eating the cost when the third prototype takes twice as long as the first.
• You are embedded in a team. Some contracts put you on a studio team as if you were a full-time employee, working on whatever the sprint backlog requires that week. There is no single deliverable to price. You are selling your time and expertise for a period.
• The technical risk is genuinely high. Porting a game to a console you have never targeted, integrating with a legacy codebase you have not reviewed, or building on top of a custom engine with no documentation. When you cannot predict the obstacles, hourly billing protects you from the downside.

For hourly contracts, I set a weekly hour cap so the studio has budget predictability: “My rate is $95 per hour, capped at 30 hours per week, so your maximum weekly cost is $2,850.” The cap prevents surprises without locking you into a fixed scope.

Matching the model to common game dev contracts

A lot of my contracts are hybrids. I will quote the first deliverable at a fixed price (often a prototype or proof-of-concept) and then switch to hourly for the production phase if the scope is still being figured out. That gives the studio a low-risk way to start and gives me the flexibility to adapt as the project evolves.

Handling Scope Creep When a Studio Asks for Just One More Feature

“Can you also add...” is the sentence that has cost me more money than any other in my career. Not because the request itself was unreasonable, but because I used to say yes without adjusting the price or timeline.

Scope creep in game development is inevitable. A designer plays the build and realizes the jump mechanic needs a wall slide. The art director sees the tileset in-engine and wants a transition variant for every terrain type. The producer gets feedback from the publisher and needs a new feature for the demo build. These are not bad-faith requests. They are how game development works. But if you absorb them for free, you are effectively cutting your own rate with every addition.

The process that keeps things clean

When a studio asks for something that was not in the original scope, I follow four steps:

1. Acknowledge the request immediately. Never let a scope change request sit without a response. The studio needs to know you heard them and are taking it seriously. A simple “Got it, let me look at what this involves” buys you time to assess without creating silence.
2. Assess the actual impact. I take a day (or at least a few hours for small changes) to figure out what the addition really requires. What new work does it create? What existing work does it affect? Does it push the timeline? I do this assessment before giving any number, because gut estimates on the spot are almost always too low.
3. Present options with costs attached. I send a short message like: “Adding wall sliding to the movement system would take about four days of additional work. At my rate, that is $3,000. We can add it to the current milestone (which pushes delivery by four days), or scope it as a separate follow-on task after the current deliverable ships. Which works better for your timeline?”
4. Get written confirmation before starting. An email, a Discord message, a Slack thread: anything in writing where the studio confirms the cost and timeline change. Then I update my records and proceed.

Why this works without creating friction

Notice I never said no. I did not push back on the idea or complain about scope creep. I just made the cost visible and let them decide. Most studios are completely reasonable about this. They are used to working with contractors, and they understand that additional work costs additional money. The friction comes when developers either silently absorb the cost (and build resentment) or push back emotionally (and damage the relationship).

Drawing the line between iteration and scope creep

Not every change is scope creep. If I am building a movement system and the studio asks me to adjust the jump height or tweak the air control curve, that is iteration on the existing deliverable. It takes minutes and it is part of the job. If they ask me to add a grappling hook mechanic, that is a new feature with new requirements, new art hooks, new edge cases, and new testing time. That is scope creep.

The line I draw is about effort and complexity. Adjustments to existing work that take less than a couple of hours are part of normal iteration. Anything that introduces a new system, a new asset type, or adds more than a few hours of work gets the change order treatment. Being consistent about where that line falls is more important than exactly where you draw it. If you sometimes absorb large additions for free and sometimes charge for them, the studio never knows what to expect, and that unpredictability causes more friction than the charges do.

Preventing scope creep before it starts

The best defense against scope creep is a clear, detailed scope definition before work begins. When I take a contract for a combat system, my scope document lists exactly what is included: the attack types, the number of enemies, whether hitbox debug tools are part of the deliverable, whether balancing passes are included or separate.

This is not about being rigid. It is about giving both sides a shared reference point. When the studio asks for something new, we can both look at the original scope and see clearly that it was not included. That makes the “this is additional work” conversation easy and natural instead of confrontational.

This matters even more when work comes through peer referrals. If another game developer sends a studio your way, your pricing and scope process is part of the first impression. A professional quote and clear change-order process reflects well on both you and the person who referred you.

Using Your Past Project Data to Estimate More Accurately Over Time

My estimates got dramatically better once I started tracking my actual hours against my original estimates on every project. It sounds obvious, but most freelance game developers I know do not do this. They finish a contract, move on, and then estimate the next one from scratch using gut feel.

Gut feel is better than nothing, but it has a consistent bias: it underestimates. You remember how long the core work took but forget about the two days you spent debugging a platform-specific audio issue, the afternoon you lost to a corrupted project file, and the three rounds of revision feedback that each took half a day.

What I track and how I use it

I keep a simple spreadsheet for every contract with these columns:

• Task description. What the deliverable was, in enough detail to be useful later. Not “combat system” but “melee combat with 3 attack types, dodge with i-frames, 2 enemy behavior trees, hitbox debug overlay.”
• Estimated hours. What I quoted before starting.
• Actual hours. What I actually spent, including revisions, debugging, communication time, and any rework.
• Variance. The difference between estimated and actual, as a percentage. A positive number means I underestimated. A negative number means I finished early.
• Notes. What caused the variance. Was it a technical surprise? Unclear spec? Revision rounds I did not account for? Scope addition I absorbed without charging?

The patterns that emerged from my data

After about 15 contracts, I started seeing clear patterns:

• I consistently underestimated integration work by 40% to 60%. Connecting my code to someone else’s systems (hooking into an existing save system, integrating with a custom UI framework, working with a studio’s proprietary audio middleware) always took longer than I expected. Now I automatically add 50% to any integration estimate.
• Revision rounds averaged 20% of the original build time. I was not accounting for the fact that every deliverable goes through at least two rounds of feedback. The studio plays the build, sends notes, I make changes, they play again. That cycle is predictable, and now I include it in every estimate.
• Audio implementation took twice as long as audio creation. This one surprised me. Composing a track or designing a sound effect was the easy part. Getting it implemented correctly (triggering at the right moment, fading between layers, handling edge cases like overlapping sounds) was where the time went. If you are pricing audio work, price the implementation separately.
• Projects where the spec was a conversation had 3 times the variance of projects with written scope documents. When the scope was “we talked about it on a call,” my estimates were off by 30% to 80%. When the scope was written down and agreed on, the variance dropped to 10% to 20%.

Calibrating your estimates over time

The point of tracking is not to become a perfect estimator. It is to know your own bias and correct for it. If your data shows you consistently underestimate by 25%, you can apply a 25% correction factor to every new estimate and immediately improve your accuracy.

Over time, you build a personal reference library. When a studio asks you to build a dialogue system, you can look at the last dialogue system you built and see exactly how long it took. When someone needs 20 character animations, you can check what 15 character animations cost you on the last project and extrapolate.

This data also makes pricing conversations easier. When a studio pushes back on a quote, you can say “Based on similar work I have done on three previous projects, this type of system takes about 80 hours to build and polish. Here is how I arrived at that number.” That is much more convincing than “I think it will take about 80 hours.”

Putting It All Together: A Practical Pricing Checklist

Here is the process I follow for every new game development contract inquiry. It works whether the project is a $2,000 sprite batch or a $40,000 systems programming engagement.

1. Get the scope in writing. Before you estimate anything, make sure you and the studio agree on exactly what the deliverable includes. If the scope is vague, push for specifics. If the studio cannot provide them, that is a signal that hourly billing is the right model.
2. Check your past project data. Have you done something similar? How long did it actually take? What was your variance? Use that data as your starting point, not a fresh guess.
3. Choose the right pricing model. Well-defined deliverables with clear scope get project-based pricing. Exploratory work, team augmentation, and high-uncertainty tasks get hourly with a weekly cap. Many contracts use a hybrid of both.
4. Build in your margin. Add 20% to 30% to your project-based estimates for unknowns. This is not greed. It is the cost of absorbing the surprises that come with every game development project.
5. Define your scope change process upfront. Before work starts, tell the studio how you handle additions: you assess, you present options with costs, they confirm in writing, and then you start. Setting this expectation early makes the conversation natural when it inevitably comes up.
6. Track your actuals. When the project is done, log your estimated hours, actual hours, and what caused the variance. Every contract you track makes the next estimate better.

Freelance game developers who build sustainable contract practices are not necessarily the most talented developers in their discipline. They are the ones who have learned to price their work accurately, communicate scope boundaries clearly, and improve their estimates with every project. Those are learnable skills, and they will protect your income more reliably than raising your rate ever will.

If you are exchanging referrals with other game developers (sending art contracts to an artist you trust, getting programming leads from a composer who knows a studio that needs systems work), having clear pricing practices makes those partnerships smoother for everyone. When you want a simple way to track referral agreements and coordinate payments as work flows between peers, PureIntro can help.

This post reflects one professional’s experience and is for informational purposes only. It is not business, legal, financial, or professional advice. Results described are individual and not guaranteed. Referral fee arrangements may be subject to state and local regulations. Consult a qualified professional for guidance specific to your situation. PureIntro facilitates referral tracking and payment processing but does not guarantee payments between users or any particular business outcome.