The One-Page Game Scope Template We Give Every New Founder

A one-page scope fits on a single sheet and answers seven questions: what the player does, why they return, what ships, what does not, which platform, what proof matters, and what the budget is. It exists so quotes are comparable and the build has a boundary. Longer documents come later.

Why this matters

A studio quoting on a vague brief has two options: pad the number to cover the unknowns, or quote low and discover them later. Both cost you.

The one-page scope is the cheapest possible way to remove that ambiguity. It usually takes an afternoon to write, and it changes the quality of every conversation that follows.

It also does something useful internally. Founders regularly discover, while filling in the last box, that they were describing two different games.

Why one page and not twenty

A full design document has a place, and it is not at the start.

Twenty pages take weeks to write, go stale the first time the prototype teaches you something, and are rarely read end to end by the people quoting.

One page forces the decisions that actually drive cost to the surface, which are scope boundaries rather than feature detail. It also fits inside a single conversation.

If it does not fit on one page, the project does not have a boundary yet. That is the finding, not a formatting problem.

The seven boxes on the page

Here is the whole template. Each box is two or three lines, not a paragraph.

Fill them in that order. Boxes one and two decide most of the rest.

How to fill the core loop box

This is the box people get wrong, so it is worth being strict.

Write one sentence in the form: the player does X, gets Y, which lets them do more X.

• Weak: "A relaxing puzzle game with beautiful art and a calm atmosphere."
• Better: "The player matches tiles to clear a board, earns coins, and spends coins to unlock harder boards."

The weak version describes a mood. The better version describes a loop, and a loop can be estimated, built, and tested.

If your sentence needs an "and also", you likely have two loops. Pick the one that the ad will show, and move the other into box four for now. There is more on this in What Is a Core Game Loop.

What goes in "explicitly not building"

This is the highest-value box on the page and the one founders skip.

Anything a reasonable person might assume is included, and is not, belongs here. Write it as a list.

Common entries worth stating outright:

1. Accounts and login
2. Cloud save and cross-device progress
3. Multiplayer of any kind
4. Localisation beyond one language
5. Live events and seasonal content
6. In-app purchases, if v1 is ads only
7. Tablet-specific layouts
8. Analytics dashboards beyond the standard events

Every line here removes an assumption that would otherwise turn into a change request. A change request mid-build is the most expensive way to buy a feature, which is covered in Changing Scope Mid-Project.

Filling boxes five, six, and seven honestly

Platform and devices. Name the oldest device that must run well. "Android" is not an answer; a specific budget handset from a few years ago is. This single line moves art budgets and performance work more than anything else on the page.

What success looks like. One result. Not four. A prototype that proves a mechanic, a soft launch that hits a retention target, a build good enough to submit to publishers. Different answers here produce genuinely different builds.

Budget and date. Write the real number. Withholding it does not produce a better price, it produces a proposal aimed at the wrong scope, and you spend two weeks discovering that.

Using it to get comparable quotes

Send the same page to three studios and the responses become directly comparable for the first time.

Look for these signals in what comes back.

• They quote the page, rather than quoting a different, larger game.
• They challenge box three or four. A studio that pushes back on scope is reading carefully.
• They ask about box five. Device floor is where experienced teams look first.
• They break the number down by phase rather than giving one lump sum.

A studio that returns a single number with no questions has either built this exact game before or has not read the page. It is worth finding out which.

What we would do

Write the page in one sitting, before talking to anyone. Do not polish it.

Then leave it for a day and read box three against box seven. Most first drafts have a feature list that does not fit the budget, and it is much cheaper to find that on paper.

Cut from box three into box four until they match. That cutting exercise is the actual work, and everything downstream gets easier once it is done.

Revisit the page after the prototype. It should change, and a scope document that never changes is being ignored rather than followed.

The short version

• Seven boxes: core loop, return reason, shipping, not shipping, platform, success, budget.
• Write the core loop as a loop sentence, not a mood.
• The "explicitly not building" box prevents the most expensive change requests.
• Name a specific oldest device, because it moves the whole art and performance budget.
• Send the same page to three studios to get genuinely comparable quotes.
• Cut features until box three fits box seven before anyone quotes.

Fill the seven boxes this week, then send the page out. If you want us to review it before you do, share the page with us and we will tell you what is missing.

Related reading: How to Write a Game Brief, Game MVP Feature List: What to Cut, and Red Flags in a Game Development Proposal.