Sonarchy

The music party game where your taste is the scoreboard. One phone hosts; the room guesses; everybody rates — out loud, out of ten.

Comment

Inspiration

It started at a family gathering. Someone would call out a category — love songs, songs to cry to — and we'd take turns picking tracks off Spotify. What made it work wasn't the music. It was the gaps between us: three generations around one table, tastes colliding and occasionally, surprisingly, agreeing.

That's the thing I wanted to keep. Not a quiz, not a playlist — the argument. Sonarchy is that game with a scoreboard bolted on: the same categories, the same taking turns, but now with timers, guessing and a rating out of ten so the room's verdict is on the record.

The first version proved the game worked. People got loud, argued over scores, queued the next track before the last one finished. It also proved the build couldn't carry it — the host fumbled between playing music and running the game, rating was fiddly, and the best moment in the room, finding out who rated your song a four, passed too quietly to land. So I kept the idea, threw away the code, and rebuilt it spec-first.

What it does

One speaker meets many controllers. One device plays the music; everyone else uses their own phone to pick, guess, vote and rank.

The host's phone is the jukebox — it plays a song out through the room's speaker. Everyone else races to name the track on their own phone, then rates it out of ten on a slider built for one thumb. Then the reveal: scores come back attributed, so everybody sees exactly who rated what.

Two cassette-tape mascots, Casey and Walker, run the show. Casey is pink, scrappy, picks fights. Walker is a green walkman, drier, the straight man. They speak in two words, always, in caps — ENORMOUS BETRAYAL, BOLD CHOICE — a hard rule that keeps them fast, quotable and readable across a crowded room. Six characters ship free; six more come with the premium pack.

No app install for guests: the host plays in the iOS app, everyone else joins from a browser with a room code. Two players get a stripped-down head-to-head mode; three or more get the full guess-and-rate round.

How we built it

A React, Vite and TypeScript client with Tailwind and Zustand, wrapped for iOS with Capacitor, on a Supabase backend. I took an AI course at TU Dublin and built this by partnering with AI on the code and the architecture, while keeping the design decisions, the product calls and the irreverent copy my own.

The game is a phase state machine — lobby, category, pick, playback, guess, rate, reveal, leaderboard — driven live by Supabase Realtime so every phone in the room turns over together. Clients can only read. Every write — every guess, every rating, every phase change — goes through a locked Postgres function, so the room's scores and the answer can't be lifted from a phone or faked in the network tab. Integrity lives in the architecture, not in hope.

Playback is YouTube's IFrame API on the host's device, with search through the Data API v3 behind a two-tier cache. Timing anchors to the host's device rather than a server clock, because Bluetooth latency is a fact of life rather than a bug to fix. RevenueCat powers the premium character pack.

The whole thing is held together by a visual invariant rig — a Playwright harness that walks real games across three browser engines and five device profiles, asserting things like "exactly one countdown per role per screen", "no sticker ever overlaps a glyph", "every clock actually ticks", and "nothing falls below the safe-area floor on the smallest supported iPhone". About 1,100 assertions a pass. Building with AI makes it cheap to write a lot of code quickly; the rig is what stops that being a liability.

Challenges we ran into

One phone has to be the whole arcade. The host's device is jukebox, screen, referee and source of truth at once, in a noisy room, over Bluetooth. That single fact sets every limit. The phone plays the audio, so it can't hide the title from whoever's holding it — which is why the host never guesses. Fairness isn't a rule bolted on; it falls out of who holds the jukebox.

Half the constraints aren't mine to change. So I ordered them and let the order decide everything after: YouTube's terms first, because breaking those ends the product rather than a feature; audio and Bluetooth physics second, because no clever mechanic survives half a second of speaker lag; fairness third, because it's the one I fully control, so it bends to fit the other two.

Songs that lie about being playable. Some YouTube uploads report themselves as embeddable and then silently refuse — no error, no event, just a player that never starts. No API predicts it. The answer was a 15-second attempt clock: if a song hasn't started by then, the room declares it unplayable and the picker gets one fresh choice from the same category. A server-side guard makes that impossible to abuse — a song that has actually started can never be declared unplayable, which closed a race we could reproduce on real phones but never in a test rig.

iOS Safari wants a gesture per media load. A host who taps play forty seconds late still has to get music. Proving that took a device test, then a machine test, and then proving the machine test would have caught the original bug.

The rig kept passing builds a human could see were broken. Every assertion tested a property — present, big enough, inside the safe area — and none tested composition. A logo sat on top of a colour strip through 253 green checks. Fixing it meant adding compositional axioms: clearance, singularity, paint order, motion. The version that shipped was found by a person and then made impossible by a machine.

Accomplishments that we're proud of

Getting a real multiplayer party game onto the App Store as a solo build, with a backend that would survive actual users rather than a demo.

The verification discipline, more than any single feature. Every finding got measured before it got believed — and four separate times a plausible-sounding argument turned out to be wrong the moment someone actually measured. Every exemption granted to the rig came with a condition attached, and one of those conditions later caught a regression introduced by my own ruling, on the exact thing that's a condition of our YouTube quota.

And the small stuff nobody notices when it works: a play button that says it's starting instead of vanishing; a countdown on every phone rather than just the host's; coming back from a backgrounded phone and still being in the game.

What we learned

The room is the product, not the interface. The best version of this isn't the one with the most features — it's the one where a phone, a speaker and six people can be loud together without the game getting in the way.

Order your constraints and the arguments stop. Naming what comes first made every later decision faster and less debatable.

Presence is not proof. A thing can be present, correctly sized, inside the safe area, and still be unreadable because something else is painted on top of it. Test what the player actually sees, not what the code says is there.

Building with AI raises the ceiling on output and leaves the floor exactly where it was. The code arrives fast; deciding what's true still costs the same. Almost everything that went wrong on this build went wrong because a plausible explanation got accepted instead of measured.

What's next for Sonarchy

Song reliability. Certain channels — the big label uploads that rank highest in search — refuse to play in an embed far more often than anything else, which means search preferentially surfaces exactly the songs most likely to fail. The next release reranks around that rather than learning from failures after the fact.

Then Android, more characters, and watching real rooms play to find out which parts of the design were right for the right reasons.

Built With

Share this project:

Updates

Submission history