WHAMI: a daily trivia game where the answer can't disagree with the audio

The problem

Daily puzzle games live or die on one thing: whether the same people come back tomorrow. The format is solved (one puzzle, everyone gets the same one, a spoiler-free grid to share), but the supply of them is now effectively infinite. AI can generate a thousand trivia questions a second, which means “we have questions” is worth nothing. Generic AI trivia is a commodity the moment it ships.

There is, however, a specific hole in the market. The daily song-guessing game that a lot of people built a morning habit around was acquired and shut down in 2023, and nothing replaced the exact thing it did: one shared clip a day, the same one for everybody, no catalogue to browse and no scores to farm. WHAMI was built around that hole rather than around trivia in general.

The approach

WHAMI is a SwiftUI app on iOS 17 with a Supabase backend, and the interesting engineering is almost entirely on the backend, in the part that has to produce a correct, playable game every single night without anyone watching.

The daily drop. Game days are counted from a fixed epoch on a 6am ET boundary. A Postgres row-level-security policy gates the question table on day_number <= whami_day_number(), so tomorrow's questions are physically unreadable by a client holding the public key. There is no way to skip ahead, because the data isn't there to fetch.

The media round. Questions 8, 9 and 10 are audio, photo, audio. Audio previews resolve against Apple's catalogue; photographs resolve against Wikimedia with license-aware attribution, get checked by Claude's vision model to confirm the image actually depicts the subject, and are cached into object storage rather than hot-linked. Answers stay locked for three seconds so a blind guess at t=0 can't farm the speed multiplier before the clip has played.

Generation that fails safely. A night's work is all-or-nothing: ten rows are written in a single insert, or none are. Days are claimed before the slow work starts, so two overlapping runs can't both generate the same day, and every status transition is fenced on the exact row the run read. The system keeps a four-day runway, retries hourly, repairs rather than deletes when it finds a day that already holds ten valid questions, and alerts before the 6am drop rather than after it.

Backward compatibility as a design constraint. Every media question carries a plain-text prompt that stands alone with no media attached. Older installs read that and play a normal question; once a version is on someone's phone there is no way to reach it, so the schema had to be additive from the start.

The decision that made it work

The obvious way to build an AI music round is to ask a model for a song and trust the answer. That fails in the worst possible way: the model names a track confidently, the catalogue returns a different recording (a live cut, a cover, a 40-second fragment), and the player hears one thing while the app insists the answer is another. No amount of prompting reliably fixes it, and every failure is visible to every player on the same day.

So resolution is the source of truth, not the model. Claude proposes a subject; whatever actually resolves in the catalogue defines the correct choice. The answer therefore cannot disagree with the audio the player hears, not because the model got it right, but because the answer is derived from the same object the player is listening to. That removes hallucination as a failure mode instead of trying to detect it.

The cost is a rejection rate of roughly 8% (some proposals simply don't exist in usable form), so the generator always proposes spares. Two filters exist only because testing found them: album-name filtering, because a track billed as a clean studio single turned out to be a live DJ set, and a duration sanity check, because the top-ranked candidate was a 40-second fragment. The rule that follows from both is that a filter never gets loosened to make a resolution succeed. A wrong recording is far worse than a missing day.

Outcomes

WHAMI is live on the App Store, free, with no ads, no tracking, and no account. You pick a player name and play. Three releases shipped in fourteen days, including the entire media round, built and submitted from the command line: signing, archive, upload, version record, and review submission all driven through the App Store Connect API without opening Xcode.

The daily generator has been running unattended against production since deployment, and the failure modes it has hit (a slow night that blew past the runtime limit, a bookkeeping row that outlived the run that wrote it) were caught by the runway check and self-healed by the hourly pass rather than by anyone noticing.

Who this is for

WHAMI is for anyone who kept a daily puzzle habit going and misses the music one specifically. It takes about ninety seconds a day and there is nothing to sign up for.

The pattern underneath it generalizes past games: a scheduled generation pipeline that has to produce correct output unattended, where the model proposes and an external system of record disposes. That same shape (durable jobs, fenced state transitions, self-healing retries, and alerting that fires before the deadline rather than after) is the one running TableFriend's reservation workers and AutoCRM's outbound engine.