Tandem.

My wife and I have been long-distance since we got married. New Jersey to Manila is a 12-hour time difference and a 8,000-mile gap that no amount of Zoom calls closes. We tried the couples apps. They handle the easy 20%: a shared calendar, a "thinking of you" button, a streak counter. None of them handle the actual hard part, which is that video calling from two different continents drops audio, screen-share on Zoom mutes the movie you are trying to watch together, and every "connection" feature reads like it was designed by someone who has never spent a year apart from the person they love.

The real problem was narrower and more specific than "we need a couples app." We needed to watch a movie together and hear the sound. We needed to play a game against each other without waiting a day for a turn notification. We needed letters, actual letters, not chat bubbles that vanish. And we needed all of it to work identically whether it was 9am in Elizabeth or 9pm in Manila.

So I built it for us first. No market research, no landing page test, just my own marriage as the spec. That constraint turned out to be the strongest thing about the product: every feature had to survive a real two-device test across a real 12-hour time difference before I trusted it, and every UX decision got graded against "would my wife actually use this tonight."

The video layer came first because it was the hardest and the most personal. I had already solved a piece of this in a side project called Watch Together, a WebRTC mesh app that transmits shared-tab audio as its own track so movie night audio actually comes through, which Zoom and Meet both drop. I ported that mesh architecture into Tandem as the "Room": one door for watching together, one for a shared focus/Pomodoro session with forced mic mute, one for a two-seat photo booth with live face tracking. Signaling rides Supabase Realtime channels, not a dedicated media server, so the whole video stack costs close to nothing to run. TURN relay through Cloudflare handles NAT traversal, which matters a lot more than STUN alone across two different carrier networks on two different continents.

The games needed two different sync models and I built both. Turn-based games (Scrabble, Chess, Connect 4, Checkers, Battleship) use one generic `couple_games` table with a kind-discriminated jsonb state column, so adding a new turn-based game costs zero migrations. Battleship is the one exception: ship positions never touch the shared row. They live in a separate `battleship_secrets` table with no INSERT policy at all, and two SECURITY DEFINER RPCs (`battleship_place`, `battleship_fire`) that re-check every authorization inside the function body, because a definer function bypasses RLS, which means the function body is the only gate that exists. Quiz, the sixth game, is fundamentally different: it is simultaneous, not turn-based, and a simultaneous general-knowledge duel cannot use a turn pointer. That forced a lockstep design, covered in the hard parts below.

The retention mechanic came from actually reading my own data. Tandem already had a "your turn" badge and a push notification, but the notification fired exactly once, from the mover's browser, and never again. Miss it and the game vanished from view forever. I rebuilt this as a pull loop: an hourly cron job checks every pending turn against the recipient's own local hours (never waking anyone at 4am), dedupes per turn number so a 40-move chess game does not spam, and caps at one push and one email per person per day. The first real run on production data found roughly 140 stale, abandoned games sitting untouched, which told me the badge alone was not enough. It never is.

Everything ships as a PWA, not an app-store app, because the whole point was to move fast without an App Store review cycle standing between "Neil wants this feature" and "Neil's wife has this feature" a few hours later. That decision shaped the release cadence: over 40 versioned releases in about six weeks, most same-day from a live feature request during an actual video call, several with an "on-device test pending Neil and Yeng" note attached because WebRTC media paths cannot be verified headlessly.

Tandem is live at tandem.my with public signup, over 800 registered users, and a working Pro tier with real paying households on a manual GCash order flow I built and verify myself. The app has shipped more than 40 versioned releases in about six weeks, most of them same-day fixes or features pulled straight from a real conversation with my wife during an actual call.

The architecture proved itself well enough to fork. Tandem Family, a family version with chores, a shared calendar, group chat, and a six-person WebRTC mesh, launched on its own domain, family.tandem.my, running on a separately provisioned Supabase project, reusing the same core patterns: the generic games table, the presence system, the TURN relay, the pull-loop retention design.

The product still runs on the same test that started it: does this actually work for a couple who is 8,000 miles and 12 hours apart. Every feature that touches live video or synced state gets a real two-device pass across that exact gap before I call it done.

1. Build for one real user with a real constraint before building for a market; the constraint does the product design for you.
2. Optimistic UI and monotonic state guards are not free: a guard that protects your own state also protects your own bugs, so failure paths need an explicit bypass.
3. A raise inside a database function rolls back every write in that same call, including counters incremented earlier in the function; security counters have to be measured after the fact, not trusted from the code.
4. Never route per-frame animation (face tracking, live overlays) through a UI framework's state layer; it will lose the race against the render loop every time.
5. A retention feature that fires once and never again is not a retention feature. Build the recheck loop before calling the notification done.
6. Ship as a PWA when the goal is speed of iteration on a live relationship with a real user testing it that same night; app-store review cycles are the wrong trade for that loop.

Tandem is proof I can take a product from a real, specific personal problem through live WebRTC infrastructure, real-time multiplayer sync, a working payment and admin flow, and a second production fork, without a team. If you need real-time, multi-user, or video-call product built and actually shipped to real users, this is the receipt.