Scope in plain language
A good estimate restates what will be built: features, platforms, content quantities and online services. If it only shows a total price and duration, you cannot compare it with anything.
Assumptions
Every estimate is built on assumptions, such as who provides art, how many levels there are or which backend is used. They should be written down. Most budget disputes come from assumptions nobody listed.
Exclusions
Just as important is what is not included: store fees, third-party licences, marketing assets, localisation, server hosting or post-launch support. Ask for exclusions explicitly.
Milestones with deliverables
Break the work into milestones, each ending with something you can play or verify. Payments tied to reviewed milestones protect both sides.
Team composition
Who will work on the project, in what roles and for how long. This tells you whether the plan is realistic and who is senior on the team.
Risks
An honest estimate names the parts that are uncertain, such as a new platform, complex multiplayer or unclear design, and explains how they will be reduced, often with an early prototype.
Change process
Games change during development. The estimate should explain how new requests are assessed, priced and approved before work begins.
Red flags
- A single number with no breakdown
- No assumptions or exclusions
- Payment mostly up front, not tied to milestones
- No mention of testing or store submission
Game Nock