Two players, one board, one clock, and a server that cannot be lied to. Real-time multiplayer is where the naive build breaks. Agencies quote $40,000 to $200,000. We build a working core in one week for $5,000.
Not the screens. These are the parts that decide whether a real-time multiplayer game works or falls over:
The server owns the truth. If the client validates moves or runs the clock, the game can be cheated. Every move and every tick has to be authoritative on the server.
Both players must land on the same server. Live game state lives in one place. Routing two independent connections to the same process, and recovering when that process dies, is the real infrastructure problem.
Fair clocks over unfair networks. A player 200ms from the server spends real seconds of their own clock on transit. Across a fast game that is enough to lose on time through no fault of their play.
Matchmaking is a contention problem. Two matchers can spot the same waiting player at the same instant and double-book them into two games at once.
Your own rank is the expensive query. The top fifty is trivial. Working out that you are four millionth means counting everyone above you, and it is the most requested personalised read on the site.
The specific decisions that make a real-time multiplayer game hold up, and that the obvious version gets wrong:
State in memory, moves on disk. A game is a few hundred bytes and lasts minutes, so the live board sits in memory where validation is instant. The append-only move log is the recovery mechanism: a replacement server replays it and carries on.
Persist the move before broadcasting it. Order matters. Acknowledge first and then crash, and recovery returns a board missing a move both players already saw, which is precisely the corruption you cannot repair.
Consistent hashing with a membership registry. Both players route to the same server by hashing the game against live membership, and a fencing token stops a replaced server from writing anything after failover.
A sorted set as the matchmaking pool. Waiting players sit in a sorted set keyed by rating, so finding the nearest compatible opponent is a range read. The claim is atomic so exactly one matcher can win a player, and the rating window widens the longer someone waits.
Credit latency back to the clock. The server stays authoritative but compensates for measured one-way latency, so sitting far from the server does not quietly cost a player the game.
A sorted set for rank as well. Rank becomes a logarithmic lookup instead of counting millions of rows. Rating is derived from finished games, so the index can always be rebuilt and updates are made idempotent by game.
Pause rather than diverge. If a game server cannot be reached the game pauses. A paused game can be recovered; two clients with different boards cannot.
The gap
A studio quote for a real-time multiplayer game usually lands at $40,000 to $200,000 over four to nine months. We build a launchable core in one week for a flat $5,000, deployed on your own accounts, with every line of code yours to keep.
A working product you can put in front of real users:
Skill-based matchmaking with a widening rating window
Real-time play over persistent connections, every move server-validated
Authoritative clocks with latency compensation
Full move history, reconnect and resume after a drop
Ratings and a global leaderboard with fast personal rank
Web and native clients
And what we would leave out. Being straight about this is the only way a fixed price means anything:
Engine-based anti-cheat, which is an offline analysis problem of its own
Tournaments and arena play
Spectating at broadcast scale
Post-game engine analysis and opening explorers
You are getting the core of the same problem the big product solved, scoped to something launchable. Not a clone of the finished article.
Yes. Turn-based and lightly real-time multiplayer all share the same shape: an authoritative server, in-memory sessions, a durable event log, and routing both players to one process. Fast-twitch shooters are a different build.
Not against the rules or the clock, because the server owns both. Detecting someone consulting an engine is a separate offline problem, and we would scope that on its own.
A free 20 minute call. We will tell you if an app like Chess.com is a fit for one week, and what it takes.
Start here: what it costs to build an app in 2026, or how the week works.