What We Learned Building Software for Gaming Platforms
Field notes from shipping software around games: identity, wallets of attention, live ops, and why a gaming client is not a normal CRUD app with a darker theme.
· Updated · 2 min read · Engineering Insights
ZarkiTech is not a game studio. We do not ship Unity titles. We have shipped software around games — including work for Nebula X Gaming in the UK — and the pattern repeats: the game is the destination, and everything else is an operations problem that pretends to be a landing page.
If you treat a gaming platform like a brochure, you will build the wrong thing.
The product is not the title
A gaming company already has (or is buying) a game. What they need from a software studio is usually one of:
- player accounts that survive store logins
- a way to run events, drops, and creator codes without a spreadsheet
- community, team, or tournament surfaces
- a back office that live-ops can actually use at midnight
That is closer to our internal platforms than to “we should make it look like Steam.” Visual language matters; the data model matters more.
Latency of meaning, not just milliseconds
Games care about tick rate. Adjacent software cares about stale meaning.
If a battle pass tier is wrong for ten minutes, support is on fire. If a creator code applies twice, finance is on fire. If a team invite can be accepted on a banned account, trust is gone.
We design these systems like we design construction ops: event-sourced where it counts, boring relational data where it does not, and an audit trail a human can read. Fancy leaderboards are optional. Correct entitlements are not.
Live ops is the real user
The player is the customer. The live-ops producer is the user of the software you are being paid to build.
Give them:
- scheduled publishes, not “we’ll deploy the JSON”
- kill switches
- impersonation-free support views
- a clear “what changed, who changed it”
If the only way to start a weekend event is a developer, you did not ship a platform. You shipped a hostage situation.
Identity is messier than you want
Players arrive from Steam, console, mobile, and Discord. Your database wants one user. Reality wants five.
The rule we keep: one studio account, many linked identities, no silent merges. Merges are a support action with a log. Silent merges create item duplication and bans that cannot be explained.
What we will not do
We will not rebuild the game. We will not promise a marketplace that clears legal in a week. We will not hide live-ops behind an engineering ticket.
We will build the operational spine — and keep it boring enough to run.
Related: scalable booking platforms (the same “inventory of moments” problem) and production NestJS backends.