Qüizo: A Multiplayer Quiz Game Built for Live Events

Most multiplayer products assume a captive, technical audience — an app already installed, a stable connection, players who'll wait through a loading screen. Qüizo's audience is the opposite: two hundred strangers on venue wifi, joining from whatever browser is already open, expecting to be playing within thirty seconds of the QR code going up. Any friction in that path — a slow join, a stalled countdown, an answer button that doesn't register — reads as the show breaking, not as a bug ticket.

On top of that, one operator has to run the entire event alone: start the game, swap in a different quiz mid-room, restart a round that went sideways, kick a player who shouldn't be there, all from a laptop, without ever taking the projector down. And because the correct answer is genuinely secret information, every layer that touches game state — the database, the server, three different serializers — has to keep it that way even while re-broadcasting the room's state multiple times a second.

We settled on the simplest onboarding we could build: a QR code and a six-character join code on the big screen, a nickname, and nothing else. No email, no password, no download — the whole "sign-up" happens in the time it takes to type six letters. The join code itself is drawn from an alphabet with the visually ambiguous characters removed, because a host reading it aloud to two hundred people can't afford a room full of players confusing a zero for an O.

The other decision everything else follows from: the server is the single source of truth for the entire game, and nothing else is trusted. Every question has one authoritative deadline, computed and stored the moment it opens — not on the client, not derived from a client timestamp — so a phone that reconnects mid-question after a dead spot in the wifi picks the countdown back up exactly where the room actually is, instead of getting a fresh twenty seconds it didn't earn.

Every mutation in Qüizo — joining, answering, starting a question, kicking a player — goes through a Server Action, never a REST endpoint; the only two Route Handlers in the app are read-only Server-Sent Event streams, and even those only ever call a read function. That single rule is what keeps the state machine honest: there's exactly one place a session's phase can change, guarded by an optimistic-concurrency version stamped on every session row, so a double-tapped host action lands as a no-op instead of skipping or duplicating a transition.

The projector, the host's controller, and every phone in the room are three views onto that same server-owned state, kept in sync over Server-Sent Events fed by a Postgres LISTEN/NOTIFY channel — with a poll every few seconds as a correctness backstop under any dropped notification. A connection that survives a dead patch of venue wifi keeps showing the last state it knew, flashes a small "Reconnecting…" pill instead of going blank, and picks the room's actual state back up the moment it's back — because the projector going dark mid-game is the one failure a room full of people all notice at once.

Three game modes run on that one state machine. Classic keeps everyone on the same question at the same time, highest score wins; Elimination knocks a player out on a wrong answer or a timeout, and records which question they died on rather than just a boolean, so a wipeout can still be ranked by how long everyone lasted. Deferred mode is the odd one out on purpose — a host opens a time-bounded window and every phone plays the whole quiz at its own pace, because the two synchronized modes are scoped to a single room by design, and Deferred exists specifically to lift that bound.

That reason is a quadratic read: every open connection independently re-reads the whole room's player list every few seconds, which works out to roughly N²/3 player rows a second across the room — about 13,300 rows a second at two hundred players, Classic and Elimination's hard cap, just to render "waiting for the host." That is exactly why Deferred mode exists: its per-player clock removes the room-wide broadcast entirely, so its read cost stays flat regardless of headcount, and the 200-player cap that bounds the synchronized modes simply doesn't apply to it.

Writing quiz questions by hand doesn't scale to a client running an event next week, so an AI agent drafts them from a one-line prompt — but it's structurally unable to touch the database. It has exactly two tools, both read-only and scoped by the caller's own client id rather than anything the model supplies, and every other capability the agent framework ships with by default — a shell, a file system, web access, sub-agents — is explicitly disabled. The model's output is a typed draft that lands in the same editor and the same validation a hand-typed question goes through; only a human pressing Save ever writes a row.

Qüizo runs in English, Spanish, and Arabic, and the two ideas of "language" are deliberately different systems: which language the host's interface renders in, and which language a quiz's content plays in, bridged in exactly one place rather than conflated everywhere. A presenter screen can carry two content languages at once for a bilingual crowd, while each phone renders in the language its own player picked when they joined — right-to-left flip included — and an unknown translation key fails as a type error at build time instead of as a blank string in front of a live room.

Beyond the core game loop, Qüizo grew into a full event-operations tool:

Qüizo went from an empty repository to a production event platform in about three weeks, built almost entirely by one engineer working with AI coding agents — a workflow documented as thoroughly as the product itself, down to a 650-line architecture doctrine the agents themselves read before touching a line of code.