Every game with a leaderboard needs a server. The obvious move is to write one: a small Node or Python service, a database, an API, some deployment. I did not do that. Candy Mass uses Firebase for sign-in, cloud saves and the global leaderboard, and there is no server code in this project at all.

That decision saved months. It also has real costs, and it is worth being honest about both.

What Firebase actually does here

Three things, and nothing else.

Sign-in. Players can sign in with a Google account. Firebase handles the OAuth flow, the token, the session, and the account recovery. I never see a password and I never store a credential.

Cloud saves. Progress is a small document: current round, score, lives, coins, which baskets are unlocked. It is written to Firestore after each round, keyed on the player's user ID. If they reinstall the app, the save comes back.

Leaderboard. One document per player holding their best score. Reading the top scores is a single sorted query.

That is the entire backend surface. Three features, zero servers, no deployment pipeline, no monthly VM bill.

What I did not have to build

Writing this myself would have meant, at minimum: a database with backups, an authentication system with password reset and email verification, rate limiting so nobody can spam the leaderboard, TLS certificates, a deployment process, monitoring, and someone to wake up if it goes down. That is a part-time job. For a one-person studio it is not a part-time job, it is the whole job.

Firebase gives all of it as a service. The free tier covers a small game comfortably. The honest trade is that I have given up control of the database layer in exchange for not having to operate it.

The security rules matter more than the code

The part that actually needed care was not the JavaScript. It was the Firestore security rules.

The rule that matters most is simple: a player may only write to the document whose ID matches their own authenticated user ID. Without that rule, any player could overwrite any other player's save file. With it, the database itself refuses the write, no matter what the client code does.

match /saves/{uid} {
  allow read, write: if request.auth != null
                     && request.auth.uid == uid;
}

Two lines. They are the difference between a cloud save system and a data breach.

The leaderboard uses a similar rule with one addition: scores may only increase. A write that lowers a player's score is rejected. That single rule blocks the most common cheat, which is not hacking the client but simply calling the write API with an enormous number.

The place it went wrong

One bug took a full evening to find and is worth writing down because it is a classic.

The leaderboard rule said scores may only go up. A player cleared their local data, which reset their local best to zero. On the next round the client tried to write zero, the rule rejected it, and the console filled with permission errors. From the player's side it looked like the leaderboard was broken.

The fix was not to loosen the rule. The fix was to make the client read the cloud value first, compare it with the local value, and skip the write entirely if the cloud value was already higher. The database was right; the client was making a pointless request.

That is the general lesson with server-side rules: when a write is rejected, the answer is almost never to weaken the rule. It is to stop making a write you did not need to make.

When this choice is wrong

Firebase is a poor fit if any of these are true:

You need real-time multiplayer with low latency. Firestore is fast but it is not a game server, and the round-trip will show.

You need to run trusted game logic on the server. Firestore rules can check who wrote what, but they cannot simulate a round. If cheating by a modified client is a serious risk, you need server-authoritative logic, which means a real backend.

Your data model is relational. Firestore is a document store. If you find yourself wanting joins, you have picked the wrong tool.

Candy Mass has none of those problems. It is a single-player game with a score list. That is exactly the shape of problem a managed backend solves well.

The honest summary

Using Firebase let a solo developer ship a game with accounts, cloud saves and a global leaderboard in a few weeks instead of a few months. The cost is dependence on a third party and less control over the data layer.

For a one-person studio building a first game, that trade is obviously correct. The alternative is not a better backend. The alternative is no backend, and no game.

← Back to all articles