Client work
PairPlays: a daily game on a real wine catalog
Client work, designed and built by Riv Lux Media.
A daily puzzle is the most durable retention mechanic on the web right now. One round a day, plus a streak and a score worth sharing.
The puzzle is the easy part. The hard part is everything underneath it.
What we built
A daily pairing challenge with a rotating puzzle, twenty levels of progression, and a player-facing wine detail card that shows real price and rating data from a live 690-bottle catalog. There's also a bug reporter wired into an admin triage view, and a tutorial video for first-time players.
Behind it: a Supabase backend, a deterministic daily rotation, and refresh tooling that keeps the catalog honest over time.
The three hard problems
Catalog truth. The game shows players real prices, ratings, and tasting notes. Real catalogs drift: bottles get repriced and vintages roll over, and some listings just disappear. A wine game built on live retail data is only as trustworthy as its refresh discipline, which means verifying the full catalog on a schedule, every bottle, with tooling that makes the job routine. It shouldn't take heroics.
Progression that measures something. Twenty levels is easy to build. Making them mean something is harder. Some levels genuinely test recall, and some exist for pacing and confidence. Which is which has to be an explicit design decision, or the game can feel like it's assessing skill while doing nothing of the kind.
An economy attracts adversaries. Any game with earned currency invites people to forge scores. Protecting it properly takes enforcement at the database layer, with the right granularity. Row-level rules and column-level permissions solve different problems, and if you choose the wrong one you leave a gap that looks closed from the application side.
What transferred to everything else we build
Sampling hides drift. Any dataset shown to users needs full verification. A spot-check isn't enough. This is now standard on every project we run.
Verify a security control against the mechanism. We adversarially review database changes before applying them, because an intuition about how data is protected, however confident, isn't the same as reading the actual permissions.
What this demonstrates
Catalog data at real scale, with tooling to verify it. Progression and economy design that survives adversarial players. Database security at the right granularity. And a daily-return format people come back to.
Last updated