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 requests without you needing to run a traditional server to do it.

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 database to babysit. No disk filling up. No 3am alerts because a machine fell over.

The canister just runs.

For gaming infrastructure, this changes everything. Leaderboard data does not live in a database I maintain. It lives in canister state, replicated across the network. Every score, every profile, every archive is on-chain.

One honest note before we go further, because I would rather you hear it from me than spot it in the network tab. CheddaBoards is not 100% serverless today. There is a small stateless proxy sitting in front of the canister for web builds. It handles CORS and request shaping. That is it. It holds no data. If it vanished tomorrow, every leaderboard, profile and archive would still be sitting in canister state, untouched.

Long term the plan is to cut that proxy out entirely and go fully direct-to-canister. At this stage it is not the priority, and honestly a thin proxy is the pragmatic call. It makes web integrations dramatically easier, and because the canister only accepts requests from authorised proxies, it cannot be bypassed or spoofed.

The state and the trust live on-chain. The proxy is just plumbing.

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 where the canister logic does the actual work. The canister does the verification. The canister issues the session. The proxy in front just passes requests along. It never holds tokens, never creates sessions, never becomes the thing you have to trust. The trust never leaves the chain.

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, with the trust anchored somewhere nobody can tamper with.

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.

You can intercept the request all you like. The validation does not happen in transit, and it does not happen on a server you can talk your way around. The trust anchor 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.

The Cheese Game

A Pac-Man-style arcade game for the Cheese Coin community on ICP. The original proof that the infrastructure worked in production, with real users, under real load.

CheddaClick

The stress test. A clicker game that hammers the score submission pipeline constantly. Fast inputs, frequent calls, continuous leaderboard updates. If something was going to break, CheddaClick would find it.

Scooter Dash

The demo. An endless runner built specifically to sit inside a developer dashboard, so anyone evaluating CheddaBoards could play a game, watch their score appear on a leaderboard, and immediately understand what they were looking at.

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 (that same proxy layer, doing honest work) 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.

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.