How to Write a Roblox Game Brief That Gets You an Accurate Quote

We read a lot of project enquiries. They range from a single line asking for a game like whatever is top of the charts this month, to forty-page design documents with every menu specified. Both make accurate quoting hard, for opposite reasons. One says too little. The other buries the handful of decisions that drive cost under hundreds that do not.

The brief you send shapes everything that follows. Two studios quoting a vague brief are pricing two different imaginary games, and the gap between their numbers tells you more about their guesses than about their rates. A clear brief gets you quotes you can compare, faster conversations, and a project that starts with fewer surprises. This guide covers what to put in it.

What a Brief Is For

A brief is not a game design document. It does not need to specify every system, because designing those systems is part of what you are hiring someone to help with. A brief has three jobs: let a developer understand the game well enough to scope it, surface the decisions that drive cost, and expose the risks early. Two pages that do those three things beat thirty pages that do not.

The Ten Sections of a Useful Brief

1. The game in one sentence

Describe what the player does every few seconds, in a single sentence. "Players defeat waves of villains to hatch pets that make them stronger and unlock new worlds." "Teams of up to eight defend a base by placing and upgrading towers between waves." If you cannot write this sentence yet, that is worth knowing and worth saying: your project starts with design work, which a good studio can scope as its own phase. Our game loop design guide explains why this one sentence matters so much.

2. Who it is for

Give an age range, and say whether the game is solo, co-operative, or competitive. Then say which devices matter. Most Roblox players are on phones, and a game designed around a keyboard and mouse needs real rework to play well on a touchscreen. If your audience is mobile-first, the developer needs to know before designing a single control.

3. Reference games, and what exactly you like about them

References are the fastest way to communicate feel, but "like Game X" on its own is ambiguous. Game X has a hundred features and you probably care about three. Name two to four games and, for each, the specific thing you want: the satisfaction of a hatching animation, the pace of the first ten minutes, the way the lobby lets friends group up. That tells a developer where the effort should go.

4. Must-haves for launch

Describe the smallest version of the game you would be proud to release, and be ruthless about it. A focused game that does one thing well can launch, gather real player data, and grow from there. A sprawling one built to a fixed budget launches thin everywhere.

5. Nice-to-haves

Everything else goes here, and the list is not wasted. It tells a developer how you see the game growing, so the launch version can be built in a way that makes those additions cheap later. Separating must-haves from nice-to-haves is the single most useful thing you can do for a quote, because it lets the core and the extras be priced separately, and lets you choose.

6. The features that drive cost

Some features look small on a list and are not. Flag these explicitly, because they move a quote more than anything else:

• Trading between players. It turns every duplication bug into an economy-wide problem, so it has to be built to a much higher standard than the rest of the game.
• Real-time competitive multiplayer. Combat that feels fair and responsive on a bad connection is a hard engineering problem, not a setting.
• Custom 3D art, animation, and effects. Frequently the largest single cost on a project.
• Cross-server systems. A global leaderboard is cheap. Cross-server matchmaking, parties, and live global events are not.
• Building and creation systems. Letting players build, save, and share creations multiplies everything that has to be tested.
• Live events and ongoing content. The tooling to run events after launch is work in its own right.

If any of these are must-haves, say so plainly rather than leaving them in the middle of a list. Our Roblox game development cost guide explains why each one moves the number.

7. Monetisation intent

Say how the game should earn: Game Passes, Developer Products, subscriptions, or nothing at all, as with many brand campaigns. You do not need prices. You do need the intent, because monetisation shapes the economy and the economy shapes progression. Our monetisation guide covers the options.

8. Art

Who is supplying it, and in what style? Do you have existing assets, a brand guide, or an artist of your own, or is the developer expected to produce everything? Attach a few reference images. Well-chosen existing assets for a first version are a legitimate way to fit a smaller budget, so say if you are open to that.

9. Budget range and deadline

This is the section people most often leave out, and the one that helps most. The worry is that a shared budget will simply be spent in full. In practice, a range lets a developer tell you what is realistic within it and propose a scope that fits, rather than quoting a version of the game you cannot afford and starting the relationship with disappointment.

For the deadline, say whether the date is fixed or flexible. Brand launches and campaigns usually cannot move, as with the virtual concert experience we built for the Swedish artist Theoz, and a fixed date changes how a project should be planned. A flexible date leaves room to adjust scope intelligently as the game takes shape.

10. After launch

Who will run the game once it is live? Do you want ongoing updates, and for how long? A game you intend to update every week for two years should be built differently from a campaign that runs for a month. Our live ops guide covers what that ongoing work involves.

A Template You Can Copy

Copy this into a document, answer each point in a few lines, and you have a brief most studios can quote from:

GAME BRIEF: [working title]

1. The game in one sentence
   What does the player do every few seconds?

2. Audience
   Age range. Phone, PC, or console first? Solo, co-op, or competitive?

3. References
   Two to four games, and the specific thing you like about each

4. Must-haves for launch
   The smallest version you would be proud to release

5. Nice-to-haves
   Everything that could arrive in a later update

6. Features that drive cost
   Trading? Real-time PvP? Custom art? Cross-server systems? Live events?

7. Monetisation
   Game Passes, Developer Products, subscriptions, or none

8. Art
   Who supplies it, style references, existing assets

9. Budget range and deadline
   A range is fine. Is the date fixed or flexible?

10. After launch
    Who runs updates, and for how long?

A Worked Example

Here is the difference in practice. This is the kind of brief we receive regularly:

Nothing in it is unreasonable to want. But it lists features without priorities, tucks two of the most expensive systems on the platform, trading and clans, into the middle of a list, says nothing about the audience, and pairs a large scope with a three-week deadline and no budget signal. Any number quoted against it is a guess. Here is the same idea as a brief that can be scoped:

The second version takes perhaps ten minutes longer to write. It can be scoped and priced accurately. It puts trading where it belongs, as a deliberate later decision rather than an assumption. And it lets a developer reply with options instead of a guess.

What to Leave Out

• Pixel-level UI specifications. Until the core loop is proven, detailed screen designs are likely to change. Describe what the UI must do, not exactly how it looks.
• Exact prices and drop rates. Those come out of economy design and playtesting, not the brief.
• Technical decisions without a reason. If you have a genuine constraint, such as integrating with an existing system, say so. Otherwise let the developer recommend an approach and explain it.
• Goals nobody controls. "It needs to go viral" is a hope, not a requirement. Describe the outcome you can plan for, such as a polished game in front of players by a date, and let the plan serve it.

What Happens After You Send It

A good developer reads a brief and comes back with questions. That is a positive sign, not a delay: it means they are thinking about your game rather than matching it to a price list. Be wary of a quote that arrives with no questions at all, particularly for a large project.

At Santoz Studios, a brief is followed by a free consultation, then a written scope listing what is included and, just as clearly, what is excluded, then a fixed quote against that scope. If the scope does not fit the budget, we say so and suggest what to cut, rather than agreeing and delivering a thinner version of everything. Our guide on how to hire a Roblox developer covers what else to look for at this stage, whoever you choose to work with.

Send Us Yours

If you have a game in mind, the template above is the best possible start to a conversation with us or with anyone else. Send us your brief, however rough, and we will tell you honestly what it would take to build. Our hire Roblox developers page explains how our engagements work.