Every answer to this question online is a range so wide it is useless. Three months to three years. This guide from Maxio Fun Studio breaks how long it takes to make a mobile game into the stages that actually consume the time, and covers the two weeks of waiting that most articles leave out entirely.

The Honest Framing

The reason the ranges are useless is that "a mobile game" covers a block puzzle one person builds in evenings and a live service title with a team of eighty. Those share a category and nothing else.

A more useful question is what the stages are and what makes each one longer or shorter. Then you can place your own project.

What follows is from our own experience shipping small casual titles, so treat the durations as one studio's figures rather than an industry benchmark. The parts that come from documented policy are marked as such.

Stage 1: Concept and Prototype

The goal here is one question: is the core loop fun when it is ugly?

A prototype is grey boxes and placeholder everything. No art, no menus, no sound. Just the thing the player does over and over, built well enough to tell whether it holds attention for five minutes.

For a casual game this is days to a couple of weeks. It is also where the most projects should die and the fewest actually do. A loop that is boring in grey boxes will still be boring with beautiful art, and the most expensive mistake in game development is finding that out after the art is finished.

Teams that take this stage seriously ship faster overall, because they throw away cheap prototypes instead of expensive ones.

Stage 2: Production

Everything that turns a loop into a game: levels, progression, menus, settings, save system, audio, the art pass.

For a small casual title this is typically one to three months of real work. The variables that move it most are how much content you need and whether you are making the art yourself.

Level count is the one people underestimate. A puzzle game with 200 hand designed levels is a fundamentally different project from one with 40, even though the code is identical. Procedural generation changes that maths, but brings its own weeks of tuning to make generated levels feel designed.

Which engine you use matters less than people expect at this scale. Our comparison of Unity, Unreal and Godot for mobile goes into where the differences actually show up.

Stage 3: Polish, and the Part Nobody Budgets For

There is a well worn observation in software that the last ten percent takes as long as the first ninety. In game development it is not a joke.

Polish is where you handle the phone ringing mid-level, the back button on the pause menu, the save that has to survive the app being killed, the tutorial for someone who has never seen your game, the screen that is a different aspect ratio, and the device from 2019 that runs everything at half speed.

None of it is visible in a trailer. All of it is the difference between a game people finish and a game people uninstall on day one.

Budget weeks, not days. If your plan has polish as a line item at the end with three days against it, the plan is wrong.

Stage 4: Store Assets and Compliance

Easy to forget and genuinely blocking.

Before you can publish you need an icon, a feature graphic, screenshots at the required sizes, a short description, a full description, a privacy policy hosted at a real URL, a content rating questionnaire, and a completed Data safety declaration covering what your game collects and shares.

The Data safety section is the one that catches people out, because it requires you to actually know what every SDK in your game transmits, including your advert network. We cover what goes into it in what data mobile games collect.

Allow a week. It is not hard work, but it is a lot of small items and any one of them missing holds up the release.

Stage 5: The Fourteen Days Most Articles Skip

This is the part that changes the answer for anyone publishing their first game, and it is documented policy rather than an estimate.

Google requires that personal developer accounts created after 13 November 2023 run a closed test with a minimum of 12 testers who have been opted in continuously for at least 14 days before they can apply for production access.

Read "continuously" carefully, because this is where projects lose weeks. A tester who opts out before the 14 days are up does not count, and opting back in later does not repair it. If you start with exactly 12 and one drops out on day 9, the clock does not simply pause. You need to be above the minimum and keep people engaged for the full period.

So the practical effect on a first release is at least two weeks of calendar time after the game is finished, plus however long it takes to recruit 12 real testers, plus the review of the production access application itself.

Plan for this at the start rather than discovering it the week you planned to launch. Recruiting testers can begin while you are still polishing.

Stage 6: Review and Release

App review on Google Play is usually faster than the equivalent on iOS, but it is not instant and it is not predictable. A first submission from a new account generally takes longer than later updates from an established one.

Build in buffer. A launch date that assumes review takes a day is a launch date you will move.

Putting It Together

For a small casual mobile game from a solo developer or a very small team, working steadily:

Prototype, a few days to two weeks. Production, one to three months. Polish, two to six weeks. Store assets and compliance, about a week. Closed testing, at least two weeks and overlapping with the end of polish if you plan it. Review and release, a few days to a couple of weeks.

That lands most first casual titles somewhere around three to six months of real effort. Our own have fallen in that range.

Two things stretch it reliably. Doing it part time around other work, which multiplies calendar time without changing the hours. And scope growth, which is the more dangerous one, because adding a feature in month two adds to production, polish and testing all at once.

What Makes It Faster

Cut content, not quality. Forty excellent levels beat two hundred mediocre ones, and ship sooner.

Pick an engine you already know. Learning a new one during a project means learning it on the critical path.

Decide monetisation early. Retrofitting adverts or purchases into a finished game touches the UI, the progression and the pacing all at once. We wrote about the trade-offs in free-to-play versus paid mobile games.

Start recruiting testers while you are still polishing, so the 14 day clock runs in parallel rather than after.

Treat the first release as a starting point. A game you can update beats a game you are still perfecting.

The Short Version

For a small casual mobile game, think three to six months of real work: a short prototype, one to three months of production, several weeks of polish that everyone underestimates, and about a week of store compliance. Then add Google's closed testing requirement, a documented minimum of 12 testers opted in continuously for 14 days for personal accounts created after 13 November 2023, which is pure calendar time unless you plan it to overlap with the end of development.