Game backend scope: what to define before you request an estimate

Why backend estimates go wrong

"How much would a backend for our game cost?" is a reasonable question with no honest answer until a few things are written down. Two studios can use the same words – lobby, accounts, dedicated servers, live operations – and mean projects that differ by an order of magnitude in effort and in monthly infrastructure cost.

An estimate becomes misleading when it silently fills gaps with assumptions. If the brief does not say who operates the servers after launch, one vendor prices a handover and another prices a year of support. If it does not separate players per match from concurrent users, one quote sizes a single server process and another sizes a fleet. Both numbers look precise; neither describes your project.

This article walks through the information that most often changes a game backend estimate, in the order we find it easiest to define. It ends with a brief table you can fill in and a short checklist to run before you send anything to a partner – including us.

If you have not yet decided on the network model itself (authority, dedicated versus listen servers, prediction), start with how to plan a multiplayer game architecture. The backend scope depends on those decisions.

1. Describe the game and the player's path through it

Start with the player, not the technology. Write down, step by step, what a player does from launching the game to finishing a session:

• Do they log in, or play anonymously?
• Do they join friends in a party, browse a server list, or press a single "Play" button?
• How long is a typical session or match, and what happens when it ends?
• What must still be there the next time they launch the game?
• What happens if they disconnect in the middle of a match?

This workflow is the most useful input a backend engineer can receive, because every step either needs a service or deliberately does not. A cooperative game where four friends join each other's sessions has a very different path into the match than a competitive shooter where strangers are grouped by skill and region. Writing the path down also exposes failure states – full servers, version mismatches, dropped connections – that need defined behaviour and therefore effort.

2. Draw the boundary between the realtime server and the backend

Online games usually have several layers: the game client, a realtime game server that simulates the match, application services that handle sessions, players and persistent data, a database, and the monitoring that tells operators what is happening. The estimate depends heavily on where you draw the lines between them.

Useful questions:

• Which state is authoritative inside the match and lives only as long as the match?
• Which data must survive the match, and who writes it – the game server, the client or a service?
• Is there a dedicated server at all, or is the session hosted by a player or a relay?
• Who already owns the realtime netcode, and is it in scope?

A common source of surprise is treating "the backend" as one thing. Netcode work inside the match (authority, prediction, replication) and service work around the match (sessions, deployment, persistence, monitoring) need different skills and are best estimated separately, even when one partner does both.

3. List the services you actually need

Make a plain list of required services and mark each one as needed at launch, needed later or not needed. Typical candidates:

• Session creation, lobbies, parties and server allocation
• Dedicated server build, containerization and deployment
• Versioned contracts between the client and the backend
• Player accounts and authentication
• Progression, inventory and in-game economy
• Analytics and LiveOps tooling
• Monitoring, logs, alerts and incident runbooks

For each item, say whether you expect an existing platform service to cover it or whether you believe a custom service is required. Integrating a proven platform service is usually smaller and cheaper to operate than rebuilding it, but the choice depends on your session model, data and cost constraints – an assessment step can settle it before the implementation estimate.

Be especially explicit about accounts, progression, economy and LiveOps. They carry security, data-protection and balancing responsibilities, and their scope varies more than any other part of a backend. A one-line "we need an economy" can mean a currency counter or a full catalogue with purchases, grants, rollbacks and fraud handling. Treat each of these as its own scoped item, not a checkbox.

4. Persistence and the data model

Whatever must survive a session needs a home, an owner and a lifecycle. Before estimating, a partner needs to know:

• What is stored: profile, unlocks, inventory, match results, settings, user-generated content.
• Who writes it: a trusted game server, a backend service, or the client (which is cheaper to build and much harder to trust).
• How often: once at the end of a match, on every pickup, or continuously.
• What must never be lost or duplicated, for example purchased items.
• Personal data: what you collect, where it may be stored, and how deletion requests are handled.
• Migration: is there existing player data that must be moved or kept compatible?

Write frequency and trust are the two answers that change the estimate most. Data written by a server at the end of a match is a modest requirement; data that the client can modify at any moment needs validation, conflict handling and an audit trail.

5. External integrations

Every external system adds work that is easy to underestimate: reading documentation, handling its failure modes, testing against its sandbox and keeping up with its changes. List each integration with its purpose:

• Platform and storefront services (identity, friends, entitlements)
• Existing backend platforms or game services you already pay for
• Hosting providers and server orchestration
• Payment, analytics, crash reporting, customer support or anti-cheat tools
• Your own existing services, if any

Note which ones are already decided and which are open. "We already use service X for sessions" removes design work but adds integration constraints; "we have not chosen a host yet" adds an evaluation step.

6. Load assumptions: players per session, CCU and request load

This is where estimates most often mix up three different numbers. Each one drives a different part of the cost, so state them separately – as ranges and scenarios, not as single figures.

Players per session is how many players share one match or room. It drives the cost of the realtime simulation: CPU and memory per server process, bandwidth per match, and how much optimization the netcode needs. It is mostly a design decision. On Bad Goons, our own multiplayer shooter in development, 64 players is a design target: it shapes the architecture, but it is not a measured capacity.

Concurrent users (CCU) is how many players are online at the same moment across the whole game. Combined with players per session, it determines how many server processes must run in parallel – and therefore hosting cost, allocation logic, scaling rules and how fast the fleet must react to peaks. It is a market assumption, and it is usually the most uncertain number in the brief.

Backend request load is how many calls the client and game servers make to backend services, and how those calls cluster. It depends on the workflow, not only on CCU: logins at peak time, matchmaking requests, end-of-match writes, inventory updates, reconnect bursts after an outage. It drives database and service capacity, rate limits and caching.

Illustrative example (not a project reference): two games with similar expected CCU can have very different backends. In the first, players spend long sessions in small co-op rooms and the backend is called mainly when a session starts and ends. In the second, short competitive matches end at the same time on many servers, each one writing results and inventory changes. The second game puts far more pressure on the services and the database, even though the CCU figure looks the same.

Also state what you need from load testing. A partner should define load scenarios for your game, measure them and report results and limits – not promise a concurrency number that has never been tested.

7. Availability and failure expectations

"It must always be online" is not a requirement anyone can estimate. Be more specific:

• Which regions must be served, and is latency a gameplay concern there?
• Is a maintenance window acceptable, and how are new versions rolled out while matches are running?
• What should players experience when a service is down – an error, a queue, offline play?
• How quickly must someone react to an incident, and at what hours?
• Is there a launch, a playtest or an event with a fixed date?

Each step up in availability adds redundancy, testing and operational process. The answers also tell a partner whether graceful shutdown, version rollout and rollback are nice to have or a launch requirement.

8. Handover and operations

The backend does not end when the code works. Someone has to deploy it, watch it and respond to problems. Define:

• Who owns the hosting and cloud accounts, billing and player data (normally you, the client).
• Who operates the services after delivery – your team, the partner under a separate support agreement, or a mix.
• What documentation your team expects: architecture and contracts, deployment steps, runbooks for common incidents, known limits, infrastructure cost drivers.
• Which skills your team already has, for example Linux, containers or the chosen cloud provider.

If ongoing support is expected, its scope and response times belong in the brief. Otherwise one estimate silently includes it and another does not. What a complete server handover contains is covered in our dedicated server handover checklist.

How we approach these questions

Our documented production work is strongest in the parts of the backend closest to the match: session and lobby integration, dedicated server deployment, client–backend contracts, monitoring and handover. Bad Goons runs Unity headless builds on authoritative Linux servers with containerized deployment, and that discipline – reproducible builds, health checks, logs, safe version rollout – shapes the questions above. Our CTO also developed the Photon-based multiplayer backend for Bean stalker's post-launch co-op in his previous role at VR Storm Studio.

Accounts, progression, economy and LiveOps are areas we scope and assess per project, starting with whether an existing platform service fits. When key assumptions are still open, the honest first step is usually a bounded assessment rather than a full implementation estimate. You can see what that covers on our game backend development page.

Backend brief template

Copy this table into your own document and answer what you can. "Unknown" is a valid answer – it tells a partner where an assessment is needed.

Estimation checklist

Before you send a backend brief to any partner, check that it covers:

• The player's path from launch to the end of a session, including disconnects and failures.
• The boundary between the realtime game server and the backend services, and who owns the netcode.
• A list of services marked as launch, later or not needed – with accounts, progression, economy and LiveOps scoped individually.
• What is persisted, who writes it, how often, and which personal data is involved.
• Every external integration, marked as decided or open.
• Players per session, CCU and backend request load stated separately, as ranges or scenarios.
• Availability expectations: regions, maintenance, rollout and failure behaviour.
• Ownership of accounts and data, operation after delivery, and the handover you expect.
• Fixed dates, existing stack and a budget range.

If several answers are still "unknown", say so. A partner who proposes a short assessment to close those gaps is giving you a more useful number than one who quotes the full project anyway. When your brief is ready, you can send it to us.