How to Hire a Mobile Game Developer: What to Ask and What to Avoid

The question that predicts success best is not "what can you build" but "what have you shipped, and what happened to it after launch". Plenty of people can build a game. Far fewer have taken one through store review, live players, and the updates that follow.

Freelancer, studio, or in-house

Freelancers are cheapest and work well for defined pieces of work: a specific feature, art, a prototype. The risk is continuity. If one person disappears, the project stops.

Studios cost more and bring a full team, so art, engineering, QA, and production are covered. You are buying process and redundancy as much as hours.

In-house only makes sense once you have ongoing work for a full team, and it is the largest fixed commitment of the three.

For a first game, a studio or a small trusted group of freelancers is usually the right call.

Questions worth asking

"Can I play something you shipped?" Not a showreel. A live game on a store, ideally one they took from concept to launch. Ask what their role actually was, because "worked on" covers a wide range.

"What happened after launch?" Retention numbers, updates shipped, problems they had to fix. Anyone who has genuinely run a live game will have stories. Anyone who has not will get vague.

"How do you handle scope changes?" There will be changes. You want a clear process, whether that is a change order or a rate, not an awkward silence.

"Who owns the code and when do I get it?" The answer must be you, on payment, with source at milestones. Anything else is a problem.

"What is your QA process?" Which devices do they test on, and who does the testing. "The developers test it" is a warning sign.

"What do you need from me?" Good teams are specific: decisions within a certain time, assets, feedback cadence. Teams that say "nothing, leave it to us" are describing a project that will surprise you at the end.

Answers that should worry you

"We can build anything." Specialists beat generalists in games.

"No, you cannot see the code until it is finished." Absolutely not.

A quote produced in minutes from a one paragraph brief. Either they have not understood the work or they intend to renegotiate later.

Unwillingness to sign a mutual NDA or to put IP assignment in writing.

Very low rates paired with very confident timelines. Games take the time they take.

How to reduce the risk

Start with a paid pilot. A prototype of your core loop, two to four weeks, fixed scope, fixed price.

You learn more from a short paid engagement than from any number of calls. You see how they communicate, whether they hit dates, what the code looks like, and whether the thing they built is fun. If it goes well, continue. If it does not, you have lost weeks instead of months.

That single step prevents most of the horror stories.