Mingo
Year
2026
Services
Summary
A competitive multiplayer word game designed from scratch in Figma and built all the way to production. Real lobbies, synchronized clocks, and rival boards that update live. Shipped in weeks as a solo designer building production code for the first time.
Play Mingo↗



Story
What if Wordle was competitive?
A couple of years ago I found myself in a familiar pattern. Wordle in the morning, results shared in the Discord chat, reacting to each other's colored squares. Fun enough, but structurally hollow.
The format had a ceiling. Once someone posted their result, the moment was done. You were comparing notes after the fact, not actually competing. The itch to beat your friends had nowhere to go.
I kept thinking about what it would feel like if everyone was guessing at the same time. Watching another board update while yours was still empty. Knowing the clock was ticking for all of you at once.
That question became Mingo. A multiplayer word game where everyone guesses the same word simultaneously, races the same clock, and watches each other's boards evolve in real time. Colors only, no letters. Enough information to feel the pressure, not enough to give anything away.
Now the word finding actually matters. Someone wins, someone loses, and everyone knows exactly where they fell short.

The game, explained
Before a game starts, the host sets three things: language, number of rounds, and time per round. A lobby code goes out in the group chat, everyone joins, and when the host hits play, every player receives the same word at the exact same moment, synchronized by a server timestamp.
That synchronization matters more than it might seem. The whole point of Mingo is shared experience under shared pressure. If players started at different times, even by a second, the game would lose its core tension.
The first letter is always revealed before guessing begins. That mechanic comes straight from Lingo, the Dutch television show that most players recognize immediately. It softens the cold start without removing the challenge, and gives the board an initial structure that makes deduction feel more directed.
From that point each player has six guesses and whatever time remains on the clock. The rivals panel is visible the whole time. You can see boards updating row by row, and the color pattern tells you whether someone is struggling or is one guess away from solving it. You cannot see their letters though. That constraint was deliberate. Full letter visibility would collapse the tension. Zero visibility would make the rivals panel pointless. Colors only sits at exactly the right point between the two.

Strategy & Research
Before opening Figma, I spent time with a single question: what actually makes Wordle work, and what does it fail to do?
The satisfying part is the deduction loop. Every guess gives you new information. The board after two guesses is a completely different problem from the board after one, and the constraints tighten in a way that feels fair. That core mechanic was worth keeping exactly as it is.
The frustrating part is the isolation. One word per day, no opponents, no stakes beyond a personal streak. The social layer is asynchronous and passive. You share a grid of colored squares, someone reacts with a thumbs up, and that is the extent of it.
Mingo needed a competitive layer on top of the same deduction loop. That meant working out what fair competition looks like for a word game. Speed matters, but it cannot be the only thing that scores. Someone who guesses correctly in two tries should beat someone who guesses correctly in five tries, even if the five-guess player was faster overall. The scoring formula rewards both accuracy and speed, using remaining guesses and remaining time as separate multipliers.
Then came the word lists. For English, I wrote filtering scripts that pulled from the standard Wordle source list and applied strict rules: five letters only, no proper nouns, no regular plurals ending in S or ES, no regular past tense verbs ending in ED. The goal was words that feel fair and common. For Dutch, I started from the OpenTaal open-source word list and applied the same filtering philosophy, which gave Dutch players the familiar Lingo experience.
UI Design
Everything started in Figma, designed component by component before any code was written.
Letter tiles have five states: empty, filled but unsubmitted, correct placement, correct letter in the wrong position, and not in the word at all. Keyboard keys track four states. Player cards come in two sizes: full for lobbies up to four people and compact for larger groups. The grid keeps the host permanently centered regardless of who joins or leaves. Each of those decisions sounds small in isolation. Together they determine whether the interface holds up when the game is actually running.
The first playable version was built entirely in Figma Make, with real game logic and no code editor involved. That choice was intentional. Before writing a line of React, I needed to know whether the game actually felt good. Figma Make let me run real sessions with real people and surface the things that did not work before any of it was baked into the codebase.
One thing those sessions made clear was that a shared start moment is essential. If different players see the board at slightly different times, the game feels unfair before the first guess. The snake loader animation was the solution. A correctly colored tile travels across every square on the board before stopping and revealing the first letter. Every player sees the same sequence. Everyone starts from the same moment. It functions as a synchronization mechanism but looks and feels like part of the game itself.

Build & Ship
The stack was chosen to keep infrastructure decisions minimal so the complexity budget could go into the game logic. React with TypeScript on Vite for the frontend. Supabase for everything else: database, authentication, and real-time multiplayer through Supabase Realtime. No custom WebSocket server, no separate auth service, no deployment pipeline beyond a Vercel connection to GitHub.
The real-time architecture is entirely event-driven. When a player submits a row, their client emits an event to Supabase, the server resolves the tile colors, and the result broadcasts to every connected player simultaneously. The rivals panel updates without any polling or manual sync. The host broadcasts round start and round end events, which means all timing is anchored to a single source of truth rather than each client counting down independently.
Before I considered the lobby stable, I wrote a stress test script that spins up to 20 simultaneous bot players. Manual testing with three or four people catches obvious bugs. It does not catch what happens when 12 players join and two get kicked at the same time, or when the overflow counter needs to recalculate while the grid is mid-transition. The bots caught both of those cases, along with several others that manual testing would never have surfaced.
The build workflow throughout the project used Claude Code with Figma MCP. Claude reads the Figma file directly, Playwright screenshots the running localhost page, and any gap between design intent and the running implementation gets surfaced immediately. That removed the usual interpretation layer where a designer hands off specs and a developer makes judgment calls about spacing, color, and behavior. The same tool held both ends, so the translation was exact.
What's next
The game is playable but not finished. A handful of multiplayer edge cases are documented and sequenced as the next build targets: shared word source per round so all players are always guessing the same word, synchronized round endings triggered by the host rather than resolving per player, and score accumulation that persists correctly across all rounds in a session.
After those ship: the post-round leaderboard with the animated score graph and podium sequence I already designed in Figma, mobile layout optimization, character customization for player profiles, sound design for tile reveals and round transitions, and eventually a public ranked mode for matchmaking outside of private lobbies.
The foundation handles the scale. The architecture is clean. What remains is building the parts that turn a working prototype into a product worth publishing.
Play Mingo↗playmingo.app
Roadmap
- Shared word source per round
- Synchronized round endings
- Score accumulation across rounds
- Post-round leaderboard
- Mobile layout
- Sound design
- Character customization
- Public ranked mode