An operating system for court-sports venues

Status: pre-MVP. Booking, memberships, the replay library and all four operational portals are built and running against a real database. Card payments are mocked pending live gateway keys, and the in-venue recorder appliance is not started. We show this as work in progress, not production.

The problem

Racket-sports venues — pickleball, tennis, padel, badminton — run on a booking sheet and a phone. The software that exists for them treats the reservation as the whole product: take the slot, take the money, done.

That leaves two problems unsolved.

The first is operational. A venue is not one job. An owner sets pricing and watches utilisation; front-desk staff deal with who actually turned up; players want to book and rebook without talking to anyone. Membership, deposits, peak pricing and no-shows each need their own handling, and a booking sheet handles none of them. No-shows in particular are a direct revenue leak that nobody measures.

The second is growth. Venues need new players to hear about them, and the marketing budget for an independent court is roughly zero. The people best placed to advertise a venue are the players already in it — but a booking confirmation is not something anyone shares.

What we built

Four surfaces, one platform. Players book, pay a deposit to hold the slot, and manage their own reservations. Owners configure courts, peak-pricing rules, deposit and no-show policy, and watch a thirty-day view of revenue, utilisation and peak hours. Front-desk staff work a day view, marking players checked in, completed, no-show or cancelled. A platform layer sits above all of it for cross-tenant metrics and per-venue feature entitlements.

Prime Replay — the actual differentiator. Every booking automatically triggers a court recording, and the player receives a shareable match replay minutes after the final point, in a personal replay library. This turns the product’s output from a receipt into a video a player posts. The venue’s marketing becomes a by-product of playing there.

Policies that protect revenue. Deposits reserve; members book free; repeated no-shows accumulate strikes. These are the rules a venue owner actually argues about, so they are configurable settings rather than assumptions baked into the code.

Multi-tenant from the first line. The data model separates venues from the outset, with feature flags per tenant. Retrofitting multi-tenancy onto a single-venue product is one of the most expensive rewrites in software; starting there costs almost nothing.

Passwordless sign-in. Players authenticate by emailed magic link. A casual user booking a court twice a month will not remember a password, and will not create an account that demands one.

Why it is built this way

Payments target the local rails. The integration targets GCash and Maya through a Philippine gateway, because that is how these players pay. A card-first checkout would be a foreign product wearing local branding.

Recording is a hardware boundary, and is treated as one. The capture appliance is a separate component, not something bolted into the web app. That boundary is what keeps a venue’s unreliable camera from being able to take the booking system down with it.

The replay is the marketing thesis, so it is being built first-class rather than added as a feature later — including the storage and signed-delivery path for clips, which is where this kind of product usually collapses under its own bandwidth bill.

Where it stands

The booking flow, memberships, the replay library and all four portals run against a real schema with row-level security. What remains before this is a production product is live payment keys and the recorder hardware.

We include it here because it shows how we approach a product we own: the multi-tenant model, the payment rails and the differentiating feature are designed in from the start, not retrofitted once there are customers to disappoint.