Building Multiplay Games with AI-Powered Development

I just launched Multiplay Games, a real-time multiplayer party games platform with 8 games: create a room, share the code, play with friends. The part worth writing about is how it got built: the entire system is AI-generated. I directed, reviewed, and merged — I didn't hand-write the code.
The problem worth solving
The hard part of a party games platform is making it feel live. The first version polled the server every two seconds, and you could feel it — two seconds of lag in a drawing game like QuickDraw is an eternity. Plus the unglamorous rest: secure score submission, room lifecycle, subscriptions.
The AI workflow
Not one giant prompt. The loop that worked:
- Architecture first. A high-level design prompt, refined over several rounds before any code exists.
- Review as a separate step. After each generated block, a dedicated review prompt: security, performance, edge cases, type safety. Splitting generation and review beats doing both in one prompt.
- Make it check its own work. Have the AI find bugs in what it just wrote and generate the tests. It reliably catches what the generation pass missed.
- Treat the prompts as an artifact. I iterated on the prompts as seriously as the code, and output quality followed.
The realtime architecture
The migration off polling went to Supabase Realtime, hybrid by design: Postgres Changes for durable state (rooms, scores, status), Broadcast channels for high-frequency ephemera like drawing strokes at 50ms intervals, Presence for who's online, and a polling fallback so a dropped connection degrades instead of breaking.
One honest caveat, cleaned up here since first publishing: these figures were the migration's design targets against the measured polling baseline, not post-launch benchmarks.
| Metric | Polling baseline | Realtime target |
|---|---|---|
| Update latency | 2000ms | ~50-100ms |
| Network requests | 150/min/player | ~5/min/player |
| Data transfer | Full state every poll | Deltas only |
In practice the difference is not subtle — QuickDraw went from unplayable-feeling to fine — but "20x faster" as a measured claim was stronger than what I'd verified.
The rest
AES-256-GCM encrypted score submissions with key rotation, Stripe subscriptions for ad-free rooms, a REST API for room management, and cron-driven cleanup — all AI-generated, migrations and API docs included. Rollout order mattered: infrastructure first, then the realtime migration game by game, Wordle as the simplest case and QuickDraw as the hardest.
What I learned
Separating generation from review, making the AI test its own code, and iterating on prompts all paid off. Harder than expected: a few games still don't feel real-time enough, long AI conversations need deliberate context management, and prompts took far more iteration than I assumed.
The bigger lesson is that the bottleneck moved: with generation this cheap, the job is choosing what to build, reviewing what comes back, and holding the quality bar. Eight months later I wrote about where this went next — handing the AI the whole maintenance loop, not just the code generation.
Try it
Stack: Next.js, Supabase Realtime, Stripe, TypeScript, Zustand, Vercel. Play at grahammakesgames.com — create a room, share the code, and see how the realtime layer holds up with your friends.