Engineering · July 6, 2026

Running Backend Services for an Indie Shmup on a Bootstrap Budget: Leaderboards, Cloud Saves, and Server Costs

The gap between "I need a leaderboard" and "I need a backend team" is much smaller than it looks from the outside, and most of that gap is closed by choosing boring, cheap infrastructure instead of building anything custom.

Published July 6, 2026

A shmup with online leaderboards and cloud saves is, from an infrastructure standpoint, a small database with a thin API in front of it, handling a request volume that's genuinely tiny by web standards even for a moderately successful release — a few thousand daily active players generates a request load that a single small server handles without strain. The instinct to reach for a scalable, distributed architecture because "it's a live service" is almost always premature for a project at this size, and it burns time and money that would be better spent on the game itself.

Managed platforms beat self-hosted infrastructure for a solo developer

Running your own server means being the one who gets paged when it goes down, patching the operating system, and handling database backups personally — all real ongoing work that competes directly with development time on the actual game. A managed backend-as-a-service platform, or even a generic managed database plus a lightweight serverless function layer, shifts that operational burden onto a provider whose entire job is keeping it running, in exchange for a monthly cost that's genuinely small at indie-game traffic levels. For a solo developer, the time saved not maintaining a server is usually worth far more than the cost difference versus self-hosting, even before accounting for the actual risk of a self-hosted service going down during a launch traffic spike with nobody available to fix it.

Design for graceful degradation, not perfect uptime

A common mistake is treating the backend as load-bearing for core gameplay, so that a backend outage takes the whole game down with it. Leaderboard submission failing should mean a retry queue and a "couldn't submit, will retry" message, not a crash or a blocked game state; cloud save sync failing should fall back to local save data rather than preventing the player from continuing. This isn't just resilience for its own sake — it also means an indie developer can tolerate a genuinely cheap, occasionally-flaky backend tier without it translating into a bad player experience, which is a meaningfully different bar than what a live-service game with mandatory always-online requirements has to hit.

Cost scales with player success, which is a good problem to plan for

The realistic cost curve for a small indie game's backend is close to flat and low for a long time, then jumps if the game unexpectedly does very well — a feature on a platform's front page or a viral clip can spike traffic by an order of magnitude overnight. Choosing a managed platform with usage-based billing rather than a fixed-capacity server means that spike costs money proportional to the actual traffic rather than either falling over at a hard capacity ceiling or requiring the developer to have provisioned (and paid for) capacity for a spike that might never come. Setting a billing alert at a sane threshold is worth the five minutes it takes, since a genuine traffic spike is a good problem but an unexpectedly large bill discovered a month later is not.

Own your data export path from day one

Every managed platform eventually gets outgrown, deprecated, or simply becomes the wrong fit as a project's needs change, and the developers who suffer most when that happens are the ones who never built an export path out of the platform they chose early on. Before committing player save data and leaderboard history to any managed service, confirm there's a documented way to bulk-export that data in a usable format — not just a promise that migration tools "exist" — and actually test that export path once with a small sample of real data rather than assuming it works. A platform migration done under time pressure, because a provider raised prices or shut down a feature with a short deprecation notice, is far less painful when the export mechanism has already been verified months in advance instead of being discovered, half-broken, during the emergency itself.

Security basics matter even at small scale

A small player base is not a meaningful defense against automated attacks — bots scanning for exposed, unauthenticated API endpoints don't care how popular a given game is. Requiring authentication for any write operation (score submission, save upload), rate-limiting by account rather than trusting client-reported identifiers, and never storing API keys or database credentials directly in a client build that players can decompile are baseline requirements regardless of project size. This connects directly to the validation work covered in server-side leaderboard validation and the integrity concerns discussed in save file integrity — both are, at their core, about not trusting data or requests that originate from a client the developer doesn't control.