One developer's PHP backend quietly ran seven games across eleven platforms for a decade

A developer has published a ten-year retrospective on a single, self-built backend that has quietly served every game they shipped: seven titles across eleven platforms, on a hosting bill of 10 to 50 euros a month. The piece, published on m2h.nl and boosted to Hacker News's front page, documents what its author calls the Game Development Toolkit, or GDT — roughly 20,000 lines of PHP running on Google App Engine with Firestore behind it, built and maintained by one person.

One backend, every game

According to the post, the games running on the system are Marooners, Verdun, Tannenberg, Isonzo, Crash Drive 2 and Crash Drive 3, joined this year by a seventh title from a different studio. Platforms include Steam, Epic, the Windows Store, PlayStation 4 and 5, Xbox One and Series, Switch, iOS, Android and WebGL.

The author says the PHP version ran for ten years with no player-visible outage, and has since been replaced by a C# version on Cloud Run as of September 2026. The economics scale to zero: with nobody playing, the service costs nothing, and for the premium titles the cost per paying player was negligible.

From throwaway scripts to a decade of service

Before the toolkit existed, the developer wrote small disposable PHP scripts for each online need — a news feed here, a version check there — and rewrote them from scratch every time. The catalyst was porting the party game Marooners to console. On PC, breakage surfaces quickly in Steam forums; on console it stays invisible until certification flags a problem.

A first attempt at telemetry, Piwik backed by Redis and set up by a freelancer, never ran properly, and the developer scrapped it rather than debug someone else's architecture. The replacement was built on App Engine and Firestore in PHP, with no schema and no framework, and was formalised with an application to WBSO, the Dutch R&D tax credit — modest money, but enough that the project was treated seriously. Much of the initial work happened over a single Christmas holiday, and integrating it into Verdun afterwards took only days.

The API root is still api_v1; the plan was that a new game would move to api_v2 only once backwards compatibility became impossible, and the post says that day never arrived.

What the toolkit actually does

The system goes well beyond an analytics dashboard:

• Crash and error reporting with screenshots and log files, organised per game.
• Cloud authentication that turns Steam tickets, Epic tokens, Windows Store and PSN identities into one user record, with bans applied per game or across every game at once.
• Typed remote configuration the client caches for a day, enabling balance changes or scheduled events without a patch.
• Append-only global statistics that a tampered client cannot rewrite — Crash Drive 3 players have collectively driven 149 million kilometres, drifted 35 million of them and pushed 38 million barrels off cliffs.
• DLC and ownership checks for Steam and Epic, so the game never has to trust the client.
• Cross-platform friends, invites and sessions built on Photon webhooks.
• Vouchers, per-platform key sets for press and testers, and a link tracker that measures actual conversions; that is how the team learned a Discord link performs roughly ten times better than the same link on Twitter.

Jenkins is wired into the dashboard, so one button starts a build and another publishes it to Steam, with per-step timing kept in the build log. Benchmarks run a scene, post the numbers and land comparable results across builds. Discord channels receive new reviews, curator mentions, crash spikes and commits. A closed-testing flow verifies on Steam that an invitee owns and has sufficiently played an earlier game, routes them through HelloSign for an NDA, links their Discord account and issues a Steam key — the author says hundreds of testers were managed this way without a single spreadsheet.

Alerts that track rates, not totals

The author describes this as the most valuable rule in the entire system: crash alerts fire when exceptions per active user pass 0.05, or when errors per session pass 1.5, rather than on raw counts. On launch day, thousands of players can be online before anything trips; years later, with a small population, a genuine spike still gets caught.

Why it matters

Most postmortems cover games; this one covers the invisible plumbing that made seven releases and a string of console ports possible. For small studios it is a working argument that a single, boring, single-owner service on managed infrastructure can handle authentication, crash reporting, remote config, build automation and testing workflows for a decade at near-zero cost — and that choices like plain PHP with no framework were features rather than compromises. Two of its design rules travel well beyond games: alert on rates rather than counts, so monitoring survives changes in player population, and keep APIs backwards compatible, so every new game lands on the same endpoint. The C# rewrite also shows the exit path: because the system stayed small and simple, one developer could replace the runtime underneath it without a multi-year migration project.