Mobile game development

The problem with commissioning a game

Two very different buyers land here. A studio or publisher already has a game, or a slate of them, and needs a slice built outside their own team — an art pass, a batch of levels, a playable prototype from a one-page concept. That brief is usually clear, the risk is schedule rather than direction, and the conversation is about capacity.

The second is a brand that wants a small game for a campaign, an event stand, or a loop inside an app it already owns. This is the more common request and the one most often quoted wrong, because what is being bought is not really a game. It is a few minutes of attention that has to survive being played on a mid-range Android phone on conference wifi, and being judged by a marketing team on whether it is enjoyable in the first fifteen seconds. The technical work is modest. The design work is not.

Both are buying the same underlying thing, and it is not code. A game is the one kind of software where the specification cannot be written in advance, because the property being specified — whether people want to do it again — is only discoverable by building it and watching someone play. This is why game budgets behave differently from app budgets, and why an honest process starts with something deliberately ugly. A concept document can describe a game perfectly and still describe a game that is boring, and no amount of art fixes that later.

How the build runs, stage by stage

1. Greybox prototype. No art, no sound, no menus, no monetisation. Boxes and circles, the core loop only, running on a real handset rather than in the editor. The single question is whether the loop is worth repeating. Two to four weeks.
2. Playtest and a genuine kill decision. People who did not build it play it, without being told how. We watch where they stop, where they repeat, and where they put the phone down. This stage is allowed to end the project, and the quote is structured so that it can without wasting the rest of the budget. One week.
3. Art, audio and content. Only now — style direction, the asset set, the level or content run, the UI, the sound. Doing this after the loop is proven means every asset is made for a shape that is already settled, instead of being redrawn when the design moves. Four to twelve weeks, depending on content volume.
4. Monetisation and instrumentation. Ad placements and their mediation, or in-app purchase, plus the analytics events that later tell you where players leave. Placement is a design decision, not a plug-in — an interstitial in the wrong slot costs more retention than it earns revenue. Two to four weeks.
5. Tuning. Difficulty curve, session length, pacing, the point where boredom sets in, the point where frustration does. This is the stage that decides whether the game is good, it is the one clients most want to shorten, and it is measured by watching real sessions rather than by opinion. Four to twelve weeks, overlapping the stages above.
6. Build, store paperwork and submission. Icons, screenshots at every required size, age and content rating questionnaires, privacy and data declarations, the release build. Two to four weeks, with store review time held outside the project timeline.

Tooling is stated up front rather than left vague: Unity for most casual and branded work, Godot where a lightweight 2D engine suits better, Unreal only when the visual target justifies its cost, plus an ad mediation network and an analytics SDK chosen with you, since both leave data in your accounts and not ours.

What sets the number inside the range

$5,000–$80,000 over 3–9 months is the widest span of any service here, because "a game" covers a two-week prototype and a two-year product with the same word. Three things decide where a project sits.

Content volume. A single-loop endless game with one art set is a different order of work from sixty hand-built levels, each of which has to be authored, balanced and tested. Content is the most predictable cost in game development and the easiest to underestimate, because level ten is quick and level sixty is not.

Whether art is original or supplied. A publisher handing over a finished art bible and asset pack removes a large, slow, iterative stage. Original direction — style exploration, character work, animation, sound — is often the largest single line in a game budget.

Prototype or live product. A prototype ends when it is playable. A live product carries a backend, accounts, leaderboards, remote configuration, ongoing events, store compliance and update cycles, and it needs someone available after launch. Those are different purchases, and it is worth being explicit about which one you want before quoting.

Where game projects come apart

Art is commissioned before the loop is proven. The most expensive mistake in this field. Concept art is exciting, it is easy to approve, and it locks the design in place before anyone knows whether the design works. When the loop later needs to change — and it usually does — the art either gets thrown away or, worse, the mechanic is bent to fit the art that has already been paid for. Greybox first exists precisely to keep that decision cheap.

The plan assumes the old install economics. Budgets still get built on the assumption that a modest ad spend buys installs cheaply enough for ad revenue to overtake it. That maths depended on tracking that is now opt-in, and it broke for everyone at once. A game planned as a self-funding business on those numbers is a lottery ticket priced as a product. Contract work and branded games do not carry that risk, which is why they are usually the better commission.

Tuning gets cut to protect a date. When the schedule slips, tuning is the stage that looks optional, because the game already runs. It is the stage that decides whether anyone reaches minute five. A shipped game with an untuned difficulty curve reads to players as unfair or dull, and the reviews say so within days — at which point fixing it costs an update cycle and the launch window is gone.