What a game actually costs to make

Cost by scale

Ranges rather than numbers, because a two-person team in one country and a ten-person team in another are different economies entirely. These are the shapes I see, counting salaries or contractor fees plus everything else, from first prototype to launch.

Two things distort those ranges more than anything else. Where your team is, since rates vary several-fold between regions, and whether people are paid at all, since a large share of indie games are funded by founders working unpaid, which is a real cost that never appears in a spreadsheet.

Where the money goes

As a share of a build budget, for a typical premium indie project. Your game will differ, but the shape is stable enough to plan against, and the first row surprises people every time.

Marketing sits outside that entirely and is discussed below, because treating it as a slice of development is how it ends up at zero.

The costs nobody budgets

This is the list that turns a comfortable budget into a tight one. None of these are optional, and most arrive near the end when the money is lowest.

1. Store fees. Steam charges a recoupable one hundred dollar fee per app, returned once the game has earned a thousand dollars. Small, but it is per app and it is due before you can publish.
2. Platform revenue share. The headline is 30 percent on Steam, dropping to 25 percent on revenue above ten million and 20 percent above fifty million, per game and only on the amount above each threshold. Console platforms are broadly comparable.
3. Age ratings. Through IARC, ratings for digital storefronts are generally issued free via a questionnaire. Standalone ratings from individual boards, and anything physical, are not.
4. Localisation. Per language, per word, plus a testing pass per language. Skipping the testing pass is how you ship a menu with clipped text in four markets.
5. Certification. Console submissions can fail, and each failure costs a resubmission and a slot in the queue. Budget at least one failure.
6. Engine and middleware. Licence terms change; check the current terms for your engine and every plugin, particularly the ones with revenue triggers.
7. Hardware. Dev kits, test devices, a machine that can build the game without taking twenty minutes.
8. Legal and accounting. Contracts, company formation, tax on foreign income, and the withholding paperwork storefronts require.
9. Runway after launch. Patches, refunds, support and the first content update all happen after revenue has slowed. Six to twelve months of it.

Marketing is not the last five percent

The most common budgeting failure in indie games, and the least recoverable, because by the time it is obvious the money is gone.

• Treat it as its own budget, not a slice of development. A common planning figure is a meaningful fraction of the build cost, and for small teams much of it is time rather than cash.
• The store page is marketing, and it is the highest-leverage asset you have. It is also cheap relative to everything else. See your Steam store page.
• Wishlists are the currency on PC, and they accumulate over months, so the page needs to exist long before launch.
• Capsule art, a trailer and screenshots are the three assets that decide whether anyone clicks. Budget them as real work rather than as an afternoon.
• Festivals, events and press outreach cost time and sometimes fees.

In-house, contract, or outsourced

The same work costs differently depending on how you buy it, and the cheapest per hour is rarely the cheapest per project.

The detail on supplier rates and pricing models is in game development outsourcing costs, and who to bring in first is in how to find a game development team.

How the money runs out

Budgets rarely fail by being wrong at the start. They fail through a sequence that is the same on almost every project I have watched.

1. The schedule slips by a third, which is the historical norm rather than bad luck, so every salaried month costs again.
2. Scope grows during production, because the game is more fun with one more system, and each system costs art, code, UI and QA.
3. The last ten percent takes thirty percent of the time: polish, bugs, certification, store pages, localisation.
4. Marketing gets funded from what is left, which is nothing.
5. Launch underperforms because nobody knew the game existed, and the post-launch runway that would have fixed it was never budgeted.

The two defences are a contingency you refuse to spend early, and a scope you can cut on purpose rather than in panic, which is scope control.

Almost no game fails because the team could not build it. Plenty fail because the money ran out three months before it was finished.

Building a budget you can defend

1. Start from the content list, not from a target number. Levels, characters, systems, screens. Count them.
2. Cost each discipline against that list rather than against a feeling about the project's size.
3. Add the invisible list from earlier in this article, item by item.
4. Add a contingency of 20 to 30 percent and treat it as untouchable until production.
5. Add post-launch runway, six months minimum.
6. Then check the schedule: multiply your estimate by 1.3 and see whether the budget still works, because that is the version that usually happens.
7. Write down what you will cut if you are 20 percent over at the halfway point. Deciding that now is far cheaper than deciding it then.