Guides
What actually drives the cost of a game
Almost every enquiry we receive contains some version of "roughly what would this cost?", and almost every article answering it online gives a range so wide it is useless — because the honest answer is that the same one-sentence description can differ in cost by more than an order of magnitude depending on decisions nobody has made yet.
So this page deliberately quotes no figures. Publishing a price range would mean turning real client agreements into public benchmarks, and inventing one would be worse than saying nothing. What it does instead is name the things that genuinely move the number, so that you can look at your own idea and see which of them apply — and so that when you do get a quote, you can tell whether it was estimated or guessed.
Last updated: 2026-08-19
01
Why nobody sensible quotes before asking questions
A game is not a fixed object with a market price; it is a bundle of decisions about scope. "A multiplayer card game" can mean four players in one room passing a phone, or a real-time service with matchmaking, accounts, anti-cheat, seasons and a support burden that never ends. Those are the same sentence and completely different companies' worth of work.
This is why a studio that answers your first email with a confident number is giving you a sales figure rather than an estimate. The useful response to "what does it cost" is a set of questions, and if those questions are good ones you are already learning something about the studio.
02
The eight things that actually move the number
In rough order of how much variance each one introduces on the projects we see.
- Content volume
- The biggest driver by a distance, and the one clients underestimate most. Levels, characters, items, questions, animations, voice lines — each is a unit someone makes, reviews and fixes. Doubling content roughly doubles the work even though the code stays the same, which is why "and then more levels later" is never a small sentence.
- Multiplayer, and which kind
- Local multiplayer is close to free. Asynchronous online play is a moderate addition. Real-time synchronised multiplayer is a different project: it brings servers, state reconciliation, matchmaking, cheating, and a permanent running cost after launch. This single decision moves budgets more than any art choice.
- Art direction and dimension
- 2D is generally cheaper than 3D, and stylised is generally cheaper than realistic — but the real cost is consistency. A distinctive style applied across hundreds of assets needs an art director holding the line, and that role is what keeps a game from looking like it was made by five people who never met.
- Platform count
- Each additional platform adds building, testing, store compliance and its own certification and update cycle. Two platforms is meaningfully more than one; console adds a certification process with its own calendar. Cutting a platform is usually the fastest way to bring a budget down without touching the design.
- Device range and performance
- Supporting older, cheaper Android hardware is optimisation work, and optimisation is engineering time that produces no new features. It is often the right investment in the Gulf, where the mass-market install base is not flagship phones — but it should be a deliberate line in the budget rather than a discovery in the final month.
- Arabic and localisation
- Built in from the start, Arabic and right-to-left support cost relatively little. Retrofitted into a finished game they are expensive, because mirroring a layout after the fact touches every screen. If Arabic matters to your product, saying so in the first meeting is one of the cheapest decisions available to you.
- Backend, accounts and data
- Login, saved progress, leaderboards, purchases and analytics each bring security, privacy and maintenance obligations. Anything storing personal data carries legal responsibilities that outlast the build, and a project that adds accounts halfway through is adding a second system, not a feature.
- Life after launch
- A game is not finished when it ships. Operating systems update, stores change requirements, servers need paying for and players find bugs. Budgeting only to launch day is the most common planning mistake we see, and it is the one that turns a successful launch into an abandoned product.
03
What matters less than people expect
The engine is rarely the cost driver clients think it is — team familiarity with it matters far more than the choice itself. Nor does the idea's originality change the price much: an unusual concept and a familiar one cost roughly the same to build if their scope matches, because the work is in the making, not the inventing.
What does quietly inflate a budget is indecision. Every reversal after work has started throws away finished output, and a project that changes its core loop late pays for the old one twice. Cheap projects are usually not the ones with the smallest scope but the ones whose scope stopped moving early.
04
How to brief so a quote means something
You do not need a design document to get a real estimate. You need four things: who plays this and on what device, what a single session looks like from opening to closing the app, what has to exist on day one versus what can come later, and what success would look like in numbers. That is usually a page, and it is enough for a studio to reason properly rather than pad against uncertainty.
That last point is the one most briefs omit and the one that changes estimates most, because uncertainty is priced. A studio that cannot see the edges of a project has to assume the expensive interpretation, so a vague brief does not get you a cheaper quote — it gets you a padded one, or a low one that will be revised upward later.
Finally, ask for the estimate as a range with the assumptions written next to it, and ask what would make it move. A studio that can tell you "this figure assumes two platforms and no live service, and doubling the level count moves it by this much" is estimating. One that gives you a single confident number for a brief you have not finished writing is not.
Common questions
Common questions
Still deciding?
Tell us what you're building and we'll give you an honest read on scope and approach — including if we think someone else should build it.