“How much does it cost to make an indie game?” looks like a pricing question, but the useful answer starts with production structure. Two projects using the same engine and the same genre label can end up with radically different budgets because scope becomes systems, content volume, QA surface, platform work and operational responsibility.
This guide builds a production model instead of a price list. Used with the QUBU Indie Game Development Cost, Scope & Timeline Calculator, it lets you compare a project in person-months, calendar time, budget and delivery risk before committing to a schedule.
1. Estimate person-months before money
A person-month is roughly one person’s full-time production capacity for one month. It is not a salary figure and it does not directly equal one calendar month. Its value is comparability: engineering, design, UI, content, QA and operations can be expressed as shared capacity before you attach your own cost structure.
If a feature carries four person-months across multiple disciplines, a four-person team cannot automatically finish it in one month. Work is not perfectly parallel, dependencies exist, and nobody spends every working hour on pure feature output. Calendar planning therefore needs a capacity model rather than simple division.
2. A bigger team does not reduce schedule linearly
Adding a second developer to a solo project can transform throughput. But as a team grows, communication, reviews, build coordination, design synchronization and integration consume a larger share of capacity. Discipline bottlenecks also matter: four engineers cannot erase a six-month art pipeline if art is the critical path.
QUBU Production Planner applies usable-capacity and coordination assumptions to the calendar estimate. The purpose is not mathematical certainty; it is to prevent a plan from pretending that headcount scales perfectly.
3. Systems define the real scope
“2D roguelite” or “online strategy” is positioning, not a production specification. Scope emerges from the systems the player uses and the team must own: combat, inventory, progression, economy, quests, procedural generation, accounts, cloud saves, matchmaking, analytics, live ops, mod support and more.
The common mistake is pricing systems only by first implementation. A leaderboard may look small until identity, cheating, season resets, ties, caching, migrations and visible failure states create extra QA and operational work. The planner therefore distributes system load across engineering, design, UI, QA and operations instead of assigning one generic complexity number.
4. Multiplayer is a production layer, not one percentage
Offline, asynchronous online, co-op and competitive real-time projects do not belong to the same delivery-risk class. Networking introduces authority, latency behavior, disconnect and reconnect handling, old-client compatibility, concurrency, persistence, matchmaking, telemetry and recovery. Some costs appear before release; others become permanent operational responsibilities.
This is why “multiplayer adds 30%” is a weak model. The stronger question is which online systems combine. Matchmaking + accounts + live ops + anti-cheat + cross-play is a different product from small peer-to-peer co-op even when both are called multiplayer.
5. Content volume can outgrow feature development
Two games can share almost the same code systems and still have very different schedules because one needs far more maps, levels, characters, items, quests, dialogue or cinematics. Content adds production, integration, localization, balance and regression-testing load. In content-heavy projects, core code can feel “done” while release remains months away.
Keep systems and content separate in scope planning. Inventory may be implemented once, but hundreds of items still need data, icons, descriptions, tuning and QA.
6. Polish is a real production budget
A prototype, a compact commercial indie release and a premium presentation do not share the same definition of done. The same feature list changes when you add transition quality, accessibility, gamepad behavior, error messaging, tutorials, save recovery, platform integration and edge-case testing.
The planner’s quality target is therefore not only visual fidelity. It represents how reliable, readable and release-ready the complete player-facing system is expected to be.
7. Use your own cost per person-month
There is no trustworthy universal person-month price for global indie teams. Employee compensation, contractor rates, country, company overhead and outsourcing structure vary too much. The default value in the tool is only an editable starting assumption, not an industry average.
A simple planning formula is risk-adjusted person-months × your fully-loaded cost per person-month + fixed external spend. Keep marketing, taxes, financing and other non-production costs separate unless you deliberately include them in your own monthly cost.
8. Why an aggressive target date raises risk
If the natural production window appears to be 16–22 months and the target is 10, the work does not disappear. Teams usually respond with more parallelism, scope cuts, or by borrowing from polish and QA. The first can increase coordination overhead; the last can increase release risk.
The planner raises schedule-pressure risk when the requested target falls materially below its capacity-based estimate. That does not mean the target is impossible. It means the plan needs an explicit answer: more capacity, smaller scope or a different definition of done.
9. Mark stretch features before the schedule slips
Scope control becomes much easier when every idea is not treated as equally mandatory. Systems that carry the player promise should be Core; systems that can be removed without breaking that promise should be Stretch. The planner’s controlled scenario excludes stretch items to reveal a practical release baseline.
This makes feature freeze less political. When time runs short, the team can return to an already-defined scope boundary rather than renegotiating the entire product under pressure.
10. How to read example production envelopes
The ranges below are not market averages. They are illustrative planning envelopes showing how the model separates project types. Your real output changes with systems, content volume, team capacity and quality target.
| Example project | Illustrative person-month envelope | Typical dominant risk |
|---|---|---|
| Solo 2D roguelite | 12–22 | Content + solo capacity |
| Two-person Steam co-op | 28–50 | Networking + QA |
| Four-person online survival | 60–110 | Persistence + content + live ops |
| Asynchronous strategy game | 30–55 | Economy + server state + UX |
| Mobile F2P game | 45–85 | Economy + analytics + live ops |
Do not copy those envelopes as a quote. Build your own game system by system in the Production Planner. The most useful output is not the final number; it is seeing which decisions dominate it.
11. Cut expensive dependency chains, not just expensive features
Removing one feature does not always save only its visible implementation cost. Sometimes that feature exists at the center of several dependencies. Removing ranked PvP, for example, can reduce anti-cheat requirements, seasonal leaderboard logic, parts of matchmaking and support burden. The strongest scope cuts remove a dependency chain rather than one isolated screen.
12. What to do after the Production Planner
Turn the resulting scope into a maintained production brief with the QUBU GDD Builder. If Steam revenue is part of the commercial plan, use the Steam Revenue Calculator to convert gross-sales assumptions into estimated developer receipts. If the project includes a persistent economy, inspect first-order source/sink pressure with the Game Economy Inflation Calculator.
13. QA is not a phase you can safely move to the end
Planning QA as “we will test when the game is finished” makes scope look smaller than it is. Every system creates its own happy path and also creates combinations with neighboring systems. Inventory plus crafting, progression plus cloud saves, and matchmaking plus parties can expand the failure surface faster than the visible feature count.
That is why the planner carries QA/release as its own discipline. In online, cross-platform or content-heavy projects, regression testing, save migrations, old-client behavior, input differences and recovery scenarios can become the real release constraint. If QA capacity is invisible, teams confuse “feature complete” with “ship-ready.”
14. Outsourcing moves capacity; it does not create free parallelism
Art, audio, localization, trailer production or external QA can solve a real bottleneck. But outsourcing still consumes internal work: briefs, references, review rounds, source-file management, integration and quality control. Teams with unclear production language can create more rework with vendors than they remove.
The planner keeps fixed external spend separate from person-month load for this reason. If outsourcing genuinely changes production capacity, also update the team and content assumptions. Adding only the invoice while leaving the schedule untouched can be misleading; shortening the schedule while pretending integration work is free is equally misleading.
15. How cost per person-month changes the same game budget
The table below is not a compensation benchmark. It is a sensitivity example showing how one fixed production scope becomes a different cash requirement under different cost structures. Assume a 30 person-month project and, for the moment, no fixed external spend.
| Cost per person-month | 30 person-month production | What changes? |
|---|---|---|
| $3,000 | $90,000 | The same scope in a lower-cost operating structure |
| $6,000 | $180,000 | Twice the cash requirement for the same workload |
| $10,000 | $300,000 | Higher fully-loaded cost without changing scope |
This is why “the average indie game costs X” is usually a weak planning statement. Team economics can multiply the budget while scope remains unchanged. Conversely, the amount of production capacity a fixed budget can buy varies with location, employment model and outsourcing structure.
16. Use a vertical slice to calibrate the model
A calculator becomes much more useful when you compare it with real production evidence. Instead of trying to perfect the estimate before development starts, build a vertical slice that includes the core loop, representative UI, persistence and, if possible, the release pipeline. Compare estimated capacity with actual capacity spent.
If the slice was estimated at 2.5 person-months and consumed 4, do not immediately multiply the entire game by 1.6. Ask why the miss happened. Was the engineering estimate low? Did the team need new tooling? Was the technology unfamiliar? Did content production move slower than expected? Did QA expose state combinations that the original model ignored? The answer tells you which discipline to recalibrate.
17. Use a scope matrix: player value × production burden
An expensive feature is not automatically a bad feature. A costly system may be the reason the game deserves to exist. A stronger scope decision evaluates each feature on two axes: differentiated player value and total production/operations burden.
- High value / low burden: usually keep it and validate it early.
- High value / high burden: treat it as Core, but attack its technical risk in the vertical slice.
- Low value / low burden: delay it until polish rather than promising it early.
- Low value / high burden: this is the strongest Stretch or cut candidate.
The Core/Stretch control in Production Planner connects that product thinking to the schedule. Because Stretch systems are already separated, the Controlled scenario can represent a real release baseline instead of an emergency feature-cut meeting.
18. Separate production budget from total company cash need
The cost of producing the game is not the same as every dollar the company may need before launch. Team capacity and direct production spend can be modeled here, while marketing, tax, financing, legal work, events, hardware, dev kits, ratings and platform-specific business requirements may need separate cash planning.
Naming those costs is better than hiding everything inside one unexplained contingency percentage. Scope is a product decision; financing is a business decision. Cutting a feature does not automatically reduce marketing spend, and raising money does not automatically make a technically dangerous scope safe.
19. When should you update the estimate?
Re-estimating the entire game every week can create noise rather than control. Update the model when a major assumption changes: a platform is added, the networking model expands, the content target moves materially, a new Core system appears, team capacity changes, or vertical-slice evidence disproves the original estimate.
Keep the old estimate. The movement itself is valuable production data. “This project started at 28 person-months and now models at 44” is not automatically a failure. The useful question is which decisions created the increase, whether those decisions improved the player promise, and whether the team consciously accepted the additional schedule and risk.
Conclusion: the useful question is “what scope can we ship safely?”
The strongest way to understand game-development cost is to translate the feature list into production load first. Person-months, calendar time, budget and risk are separate but connected variables. If scope is unclear, budget creates false precision. If capacity is ignored, schedule becomes unreliable. If QA and operations are invisible, the release plan is incomplete.