How It Actually Works

From the Kitchen

Every service has a prep list. Before the doors open, before a single order comes in, everything has to be ready. Stocks made. Sauces reduced. Proteins portioned.

The reason kitchens run smoothly during service isn't talent. It is preparation. The chaos is absorbed before the customer ever arrives.

CheddaBoards is the same idea applied to game development.

Before you ship your game, the backend is already running. The leaderboards are configured. The auth is wired up. The anti-cheat is active. You walk into service with your mise en place done.

Here is how that actually works under the hood.

The Problem I Was Solving

When I started building games in 2024, I kept hitting the same wall.

Every time I wanted to add something that made a game feel real — a leaderboard, a login, a score that persisted between sessions — I had to spin up infrastructure. A server somewhere. A database. Environment variables. Monthly costs. Things that could go down.

For a solo developer coding between shifts, that overhead is a killer. Not just the cost. The maintenance. The mental load of running infrastructure alongside building a product.

I wanted to add a leaderboard to a game the same way I would add a button. Drop it in, configure it, move on.

That did not exist. So I built it.

What a Canister Actually Is

CheddaBoards runs on the Internet Computer Protocol — ICP for short.

Most people hear blockchain and think tokens, speculation, wallets. ICP is doing something more interesting than that. It lets you deploy code that runs on a decentralised network of nodes, stores its own state, and serves HTTP requests — without a traditional server anywhere in the picture.

That unit of deployment is called a canister.

Think of a canister like a tiny, self-contained process. It has memory. It has logic. It can receive calls from the outside world and respond to them. And because it runs across a network of independent nodes rather than a single machine, there is no single point of failure to bring it down.

No server bill. No uptime monitoring. No 3am alerts because a database went down.

The canister just runs.

For gaming infrastructure, this changes everything. Leaderboard data does not live in a database I maintain — it lives in the canister state, replicated across the network. Score submissions do not hit a REST endpoint on a server I am paying for — they hit the canister directly.

That is the foundation CheddaBoards is built on.

Authentication Without a Backend

The question I get asked most: how does login work if there is no server?

Traditional OAuth flows need a backend. You redirect the user to Google, Google sends a token back to your server, your server validates it and creates a session. The server is the trust anchor.

CheddaBoards removes the server from that equation.

Internet Identity — ICP's native authentication system — handles cryptographic identity on-chain. A player creates an Internet Identity once and uses it across every ICP application. No password. No email. Cryptographic keys stored on their device.

For Google and Apple login, I built a cross-domain authentication flow that validates tokens directly in the canister logic. The canister does the verification. The canister issues the session. No middleware. No server sitting in the middle handling tokens.

The result: a player logs in with their Google account, and that identity is tied to a persistent on-chain profile that follows them across every game using CheddaBoards.

Getting that cross-domain auth working correctly took longer than almost anything else in the build. Reducing the latency from 3-4 seconds down to under one second took even longer. But it was worth it — authentication that feels instant and infrastructure that has no single point to attack or fail.

Leaderboards That Run Themselves

Here is the feature that made the most developers raise an eyebrow when I showed them.

Timed leaderboards — weekly resets, seasonal rankings, archived history — are something almost every competitive game wants. In a traditional setup, you would run a scheduled job somewhere. A cron task, a managed scheduler, something external that fires at the right time and resets the board.

That external thing can fail. It can drift. On reset day, if it does not fire, your leaderboard just sits there.

In CheddaBoards, the reset logic lives inside the canister itself. You configure a leaderboard with a reset interval — daily, weekly, custom — and the canister handles it autonomously. When the interval expires, it archives the current results, resets the live board, and keeps the historical data intact.

No external scheduler. No maintenance window. No reset failures.

From a developer's perspective, you set it up once. It runs forever.

Anti-Cheat at the Infrastructure Level

Score validation is where a lot of game backends are genuinely weak.

If your leaderboard accepts scores from client-side calls, it is trivially easy to spoof. Intercept the request, change the value, replay it. Done. Your leaderboard fills up with impossible scores and legitimate players stop caring.

CheddaBoards handles this differently because the canister runs the validation logic — not the client.

When a game session starts, the canister issues a signed session token. Scores submitted at the end of that session are validated against it. The canister checks the math. It checks the timing. It checks rate limits. It checks statistical plausibility against the player's history.

There is no request to intercept because the trust anchor is not between the client and a server — it is inside the canister itself.

For a solo indie developer, this means you get anti-cheat that would cost serious engineering hours to build from scratch, included by default.

What It Looks Like to Integrate

I built three games on CheddaBoards to prove the integration was actually as simple as I wanted it to be.

Each game runs the same backend. Each player profile carries across all of them. That cross-game identity is one of the things I am most proud of.

Where It Is Now

CheddaBoards ships with Godot and Unity SDKs, a REST API for everything else, and is listed on the Godot Asset Library. The docs are live on GitHub. We are on version 1.10.0.

500+ players are already on it — before any real marketing, purely through word of mouth inside the ICP developer community and people discovering the games.

Next issue I will talk about the part of this story I have not written about yet — how I actually learned to do all of this, starting from zero, in the gaps between shifts.

That one gets a bit more personal.

One Thing From the Kitchen

In a professional kitchen, the equipment does not get credit. The stove does not get a mention in the review. The pass does not appear in the write-up.

But a kitchen without reliable equipment produces inconsistent food. Every chef knows this. You can have the best team in the world and a faulty oven will undo them.

Infrastructure is the same. Players do not think about your backend. They should not have to. But the moment it fails — the moment a score does not save, a leaderboard goes stale, a login breaks — they feel it immediately.

CheddaBoards is the equipment. Built to not be noticed.