Ten Questions to Ask a Game Studio Before You Sign

The ten questions that matter cover four areas: how the studio works, who will actually do the work, what happens to the code, and what happens when something goes wrong. A portfolio tells you a studio can ship. These tell you what shipping with them will be like.

Why this matters

Choosing a studio is the largest single decision in an outsourced build, and most founders make it on portfolio and price.

Both are poor predictors. A strong portfolio may belong to people who have left. A low price may reflect a scope the studio has quietly reinterpreted.

The questions below take one call. They also filter for something useful on their own: how a studio answers an uncomfortable question tells you a great deal about the next six months.

You are not buying a game. You are buying six months of working with a specific group of people.

Why the answers matter more than the portfolio

A portfolio is a record of outcomes under conditions you cannot see.

You cannot tell from a finished game whether it shipped on time, whether the client was happy, whether the scope survived, or whether the team that built it still works there.

The questions below are designed to be difficult to answer well without genuine experience. Vague answers are informative in themselves.

Questions about process

1. What does your first month look like on a project like this?

Listen for discovery, a technical plan, and a risk list. A studio that starts building in week one is either extremely confident or has not read your brief.

2. How do you handle a milestone we are not happy with?

You want a described process: a review window, written feedback, a rework path, and what happens if disagreement persists. Silence here means you will be inventing the process during a dispute.

3. How often will we see a running build, and on what?

The answer should be weekly at minimum, on a real device, not a video. Studios that show video rather than builds are managing the impression rather than the project.

Questions about the team who will actually do the work

4. Who specifically will be on this project, and what else are they on?

Named people, with their allocation. Agencies frequently sell with senior staff and deliver with juniors, and asking directly is the simplest guard against it.

5. What happens if one of them leaves mid-project?

You are listening for redundancy and documentation, not for reassurance. A studio that says nobody leaves is not answering.

6. Which parts of this will you subcontract?

Subcontracting is normal and fine. Undisclosed subcontracting is a problem, particularly for ownership, since a chain of contracts is where rights get lost.

Questions about code and ownership

7. When do we own the code, and what exactly does that include?

The answer you want is progressive transfer as milestones are paid, covering source, assets, and project-specific tooling. The detail is in Who Owns Your Game IP.

8. What third-party assets and licences will be in the build?

A studio that has thought about this can answer immediately. A studio that has not will discover the problem during your diligence, or worse, after launch.

9. Can another team pick this up from a clean checkout?

This is the continuity question, and it is the one that most affects your leverage. Look for documentation, a reproducible build, and a willingness to demonstrate it. The full test is in Technical Due Diligence.

The question about what happens when it goes wrong

10. Tell me about a project that went badly, and what you changed afterwards.

This is the most informative question on the list.

Every studio with real history has one. A specific story with a specific lesson signals experience and honesty. A claim that nothing has gone wrong signals either a short history or a studio that will not tell you when something does.

Listen for whether they take responsibility for the part that was theirs. A story where the client was entirely at fault is a preview of how your project will be described later.

Answers that should worry you

Six patterns worth treating as findings.

The fifth deserves emphasis. A studio that agrees with everything is not being easy to work with, it is deferring every judgement to you. The value of an experienced partner is partly in being told no, which is covered in Your Game Studio Partner Should Say No.

Questions they should ask you

The conversation runs both ways, and a good studio will interrogate your brief.

Expect questions about your device floor, your success criteria, your budget, who makes decisions on your side, and what is explicitly out of scope. A studio that asks none of these is preparing to build whatever is cheapest to interpret.

If they push back on your feature list, that is a positive signal rather than a negative one.

What we would do

Ask all ten in one call, and take notes rather than recording impressions. Compare studios on the answers side by side afterwards, because the strongest impression in the room is often the best salesperson rather than the best builder.

Send the same one-page scope to each studio first, so the answers are about the same project. The template is in The One-Page Game Scope Template.

Then weight questions four, seven, nine, and ten most heavily. Team, ownership, continuity, and honesty predict the experience better than anything else on the list.

The short version

• Ask about process, the actual team, code ownership, and failure.
• Require named people with stated allocation, and ask what happens if they leave.
• Ownership should transfer progressively and cover source, assets, and tooling.
• The clean checkout question is the one that protects your leverage.
• The best question is what went wrong on a past project and what changed.
• A studio that agrees with everything is deferring every judgement to you.

Run these ten on your next call and write the answers down. If you want to put them to us, start a conversation.

Related reading: How to Choose a Game Development Studio, Red Flags in a Game Development Proposal, and Structuring Milestone Payments.