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, a streak, a score worth sharing.
The hard part is never the puzzle. It is everything underneath it.
What we built
A daily pairing challenge with a rotating puzzle, twenty levels of progression, a player-facing wine detail card rendering real price and rating data from a live 690-bottle catalog, 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, vintages roll over, listings disappear — so a wine game built on live retail data is only as trustworthy as its refresh discipline. That means full-catalog verification on a schedule, not spot-checks, and tooling to make that routine rather than heroic.
Progression that measures something. Twenty levels is easy to build and hard to make meaningful. Deciding which levels genuinely test recall, and which exist for pacing and confidence, is a design question that has to be made explicit — otherwise a game can feel like it is assessing skill while doing nothing of the kind.
An economy attracts adversaries. Any game with earned currency invites people to forge scores. Protecting that properly means enforcement at the database layer with the right granularity — row-level rules and column-level permissions solve different problems, and choosing the wrong one leaves 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, not a spot-check. This is now standard on every project we run.
Verify a security control against the mechanism, not the intuition. We adversarially review database changes before applying them, because a confident reading of how data is protected is not the same as reading the actual permissions.
What this demonstrates
Catalog data at real scale with verification tooling; progression and economy design that survives adversarial players; database security at the right granularity; and a daily-return format that people come back to.
Last updated