playvolley

One app on iPhone and in the browser, 67 tables, 2 languages, 71 leagues of official data

The problem

Berlin volleyball runs on WhatsApp groups and word of mouth. A host posts a session, twenty people reply, nobody knows who is actually coming, and the official league tables sit on a federation site that nobody opens on a phone. Paul plays and coaches in that scene, so the app is built from the inside, not from a brief.

The system

playvolley is a Next.js web app wrapped in Capacitor, so the same code runs as a native app on iPhone and in any browser, in German and English at exact key parity. Hosts create open sessions, matches, trainings or tournaments from one form: indoor or beach, capacity, players per side, a minimum to run, a level from 1 to 12, waitlist and sign-up cutoff. Players sign up, chat with the group and split the court cost. Official tables for 71 leagues in Berlin and Brandenburg come from the federation's data, cached and refreshed every 12 hours, so a normal visit never waits on the source. Behind it: Supabase with 67 tables and row-level security, roughly 60 database functions, data export and account deletion for GDPR, and Stripe Connect for payments.

What it does now

It is built and runs at playvolley.net and on iPhone. Every change goes through the same rules as this site: both languages complete or the build stops, and a person tests the flow on a phone before it ships. The app is our answer to the question every studio gets: can you write real code, or only wire tools together?

Where AI checks and where it decides

Step	Who decides
Code, migrations and translations	AI drafts in Claude Code, a person reviews and tests every change
Who plays: sign-ups, waitlist, no-shows	The host decides, the app records
What the app says about a league	Federation data only, never generated