Red Flags in a Game Development Proposal

A good proposal names the team, breaks the work into phases with deliverables, states assumptions, and says what is out of scope. Six things should give you pause: a single lump sum, no named team, vague deliverables, no mention of testing, a timeline with no buffer, and no questions asked about your brief.

Why this matters

The proposal is the first real work product you see from a studio, and it is a fair sample of how they think.

A proposal that is careful about scope, honest about unknowns, and specific about people usually comes from a team that works the same way. One that is a price and a paragraph usually does not.

Reading it well costs an hour and can save the project.

What a good proposal contains

Before the red flags, the baseline. A strong proposal includes:

• A restatement of your goal in their words, which shows they read the brief.
• The scope, broken into phases, each with a deliverable you could open.
• What is explicitly excluded, which is the section that prevents most later disputes.
• A named team, with roles and allocation.
• Assumptions and dependencies, including what they need from you and when.
• A phased price tied to those deliverables.
• Risks, named, with how each would be handled.
• What happens after delivery: handover, support, and ownership.

If most of these are present, you are dealing with an experienced team even if you end up choosing somebody else.

A proposal is a studio's first deliverable. Judge it the way you would judge the tenth.

Red flag: a single lump-sum number

One number for the whole project, with no breakdown.

This means one of three things: the scope was not analysed, the price is a guess with padding, or the studio intends to interpret the scope later. None is good.

It also removes your ability to compare. Two lump sums for the same brief tell you nothing about what either includes.

The question that exposes it: "Can you break this into phases with a deliverable and a price for each?" A studio that has done the analysis can answer in a day. One that has not will resist or produce something arbitrary.

The payment structure that follows from a proper breakdown is in Structuring Milestone Payments.

Red flag: no named team

The proposal describes capabilities rather than people.

This is common and it matters, because the gap between a studio's best people and its available people can be large. Selling with seniors and delivering with juniors is a known pattern.

The question: "Who specifically will work on this, what is their allocation, and what else are they on during this period?"

Also ask what happens if one of them becomes unavailable. You want to hear about documentation and overlap, not reassurance.

Red flag: vague deliverables

Phrases like "core gameplay complete", "art pass", or "polish phase" with nothing testable attached.

Every one of those is an invitation to disagree later, because neither side wrote down what finished means.

The question: "What would I be able to do with the build at the end of this phase?"

The answer should be something you could verify without an engineer, such as playing three levels on a device without a crash. If the answer stays abstract, the deliverable is not defined.

Red flag: no mention of testing or QA

Testing appears nowhere, or appears as a single line at the end.

Two problems. The obvious one is that quality will be found by your players. The subtler one is that a proposal without QA is usually a proposal whose price excludes it, so the number is not comparable to one that includes it.

The question: "How much of this estimate is testing, and on which devices?"

A good answer names a device matrix and a share of the schedule. The device floor question in particular drives real cost, per Shipping on Android.

Red flag: a timeline with no buffer

Every phase is sized exactly, tasks run back to back, and the plan assumes nothing is learned along the way.

Game development discovers things. A plan with no slack does not survive the first discovery, and the consequence lands on either quality or your budget.

The question: "Where is the contingency in this plan, and what happens to the date if a phase runs over?"

Look for either explicit buffer time or a stated policy on what gets cut first. A studio that has thought about the trade in advance is far easier to work with when it arrives.

Red flag: no questions about your brief

The proposal answers your brief exactly as written, with no clarifications and no challenges.

Briefs are always incomplete. A studio that asked nothing either did not read it closely or intends to interpret the gaps in their own favour.

The question: "What was unclear in our brief, and what assumptions did you make?"

A good studio has a list ready. Pushback on your feature list is a positive signal, not a negative one, which is the point of Your Game Studio Partner Should Say No.

Two more worth noticing

Ownership handled vaguely. If the proposal does not say when rights transfer and what they cover, the contract will favour the studio. Ask directly, per Who Owns Your Game IP.

A price far below the others. Sometimes it reflects a genuine cost base. More often it reflects a smaller scope that has not been stated. Ask what is excluded rather than assuming a bargain.

What we would do

Send the same one-page scope to every studio so proposals are comparable, using The One-Page Game Scope Template.

Then read for structure before price. A proposal with named people, testable deliverables, stated assumptions, and a buffer is worth more than a cheaper one without them, and the difference usually shows up in month three.

Ask the six questions above, in writing, and keep the answers. They become the basis of the contract, and a studio that answers them clearly has already told you a great deal about how the project will run.

The short version

• A good proposal names people, phases the work, states assumptions, and excludes explicitly.
• A lump sum with no breakdown means the scope was not analysed.
• Deliverables must be things you could verify without an engineer.
• A proposal with no QA line is not comparable to one that includes it.
• A timeline with no buffer will be paid for in quality or budget.
• A studio that asked nothing about your brief will interpret the gaps themselves.

Read your current proposals for structure before price, and ask the six questions in writing. If you would like us to bid against the same page, send it over.

Related reading: Ten Questions to Ask a Game Studio, How to Read a Game Development Quote, and Why Game Dev Quotes Differ.