Owning Your Backend: Build, Buy, or Rent

A game backend handles identity, saved progress, remote configuration, and anything that must be authoritative. For most mobile games a managed service covers all of it. Custom becomes worth building when your economics depend on something no service does well, which is rare before a game has scale.

Why this matters

Backend is where small teams spend engineering time that produces no player-visible value, and where costs appear suddenly at exactly the moment a game succeeds.

It is also a diligence topic. Investors read a custom backend as cost risk and key person risk unless there is a clear reason for it, per What Investors Mean When They Ask About Your Tech Stack.

Deciding deliberately is worth an afternoon.

What a game backend is responsible for

Separate what a backend must do from what it could do.

Usually necessary:

• Remote configuration. Changing values without shipping a build. The highest-value backend feature for most games and the cheapest to obtain.
• Cloud save. Progress that survives a lost phone, covered in Save Systems That Do Not Corrupt.
• Analytics ingestion, which is almost always a third-party service.

Necessary only for some games:

• Authoritative state, where the server decides outcomes because the client cannot be trusted.
• Player-to-player interaction: leaderboards, guilds, messaging, matchmaking.
• Server-driven content, such as live events and scheduled rotations.

Rarely necessary early: custom matchmaking, real-time simulation, and bespoke economy services.

The question is not whether you need a backend. It is which of these six things you need, and whether anything on the list requires you to write code.

Managed services compared

The options fall into three groups, and the trade is consistent.

For a first mobile title, a game backend platform or a general application platform covers everything above with configuration rather than engineering.

Check three things before committing: whether progress data can be exported in bulk, whether pricing is per active user or per operation, and whether the service supports the regions your players are in.

Cost at 1K, 100K, and 1M players

The shape of the curve matters more than any specific figure, since pricing changes.

At around a thousand daily players, nearly everything is free or close to it. Every option looks identical at this scale, which is exactly why it is a poor moment to over-engineer.

At around a hundred thousand daily players, differences become visible. Per-active-user pricing starts to be a real line, and inefficient patterns such as frequent polling or oversized save payloads begin to cost real money.

At around a million daily players, backend cost becomes a genuine business input. This is where teams either optimise heavily or move, and where a service chosen for convenience can become the largest variable cost in the game.

Three practices keep the curve manageable at any scale.

1. Batch and throttle. Most cost is request volume rather than data volume.
2. Keep payloads small. Save files that grow without bound are a common and avoidable expense.
3. Cache aggressively on the client. Remote configuration does not need fetching every session.

Model the cost at your expected scale before choosing, and specifically model the successful case rather than the expected one.

Lock-in and migration risk

Lock-in is the real cost of a managed service, and it is worth pricing rather than avoiding.

Two things determine how bad it would be.

Data portability. Can you export player data in a usable form, in bulk, without support intervention. Check this before adopting, not when you need it.

Interface depth. A backend accessed through a thin layer of your own code can be swapped. One whose calls are scattered through gameplay code cannot.

That second point is entirely within your control, and it is the single most useful architectural decision here. Put every backend call behind your own interface from the first day. It costs almost nothing and it converts a migration from a rewrite into a replacement.

When custom is genuinely worth it

Four situations justify building.

1. The server must be authoritative because cheating would break the economy, and no service models your rules.
2. Real-time simulation, where latency requirements exceed what a general service provides, per Multiplayer Games: Cost and Complexity.
3. Scale where managed pricing exceeds infrastructure cost by a wide margin, which requires a genuinely large player base.
4. A regulatory requirement about data residency or handling that no available service satisfies.

Notice that three of the four only apply after success. That is the pattern: build custom when the game has proven it needs it, not in anticipation.

Building early also carries a hidden cost. Every hour spent on backend is an hour not spent on whether the game is fun, which is still the thing most likely to end the project.

What we would do

Start with remote configuration and nothing else. It delivers most of the practical value of a backend, it is available from several services for very little, and it changes how quickly you can tune a live game.

Add cloud save when players have enough progress to be upset about losing it, which is later than most teams assume.

Put everything behind your own interface from the first call. Then model the cost at ten times your expected scale, and revisit the decision only when a specific need appears that the service cannot meet.

The short version

• Most mobile games need remote configuration, cloud save, and analytics, and nothing more.
• A managed service covers all three with configuration rather than engineering.
• Check data export, pricing basis, and regional support before adopting.
• Cost is driven by request volume, so batch, throttle, and cache on the client.
• Wrap every backend call in your own interface to keep migration cheap.
• Build custom after a game proves it needs it, not in anticipation.

Put your backend calls behind one interface this week, whatever service you use. If you want a cost model at your expected scale, tell us about the game.

Related reading: Does Your Game Need a Backend, Save Systems That Do Not Corrupt, and Multiplayer Games: Cost and Complexity.