The platform
Members, waivers, check-in, doors, bookings, money, messaging — fifteen things every club needs, built once and maintained for all of them. Your sport's module is the small part. This page is the large part.
The core
Maintained once, for everybody. A fix to the waiver engine is a fix at every venue on the platform, whatever sport they happen to play.
The four pieces
The website is static and can go live on its own. The console and the app both talk to the same API, which serves every venue on the platform at once.
A drop-in replacement for the venue's current site. Plain HTML, CSS and vanilla JavaScript — no Node, no build server, nothing to keep running. One self-contained directory per venue, uploaded to their own domain.
Where the venue actually runs. The desk, the office, the committee. Rosters, approvals, the schedule, the till, the rota, the broadcast — and the vertical's own tooling sitting alongside it.
The members' side. Their next booking, their card, their waiver, their bill. A rotating QR code for the door that works with no signal at all.
One deployment serving every venue on the platform. Tenancy is enforced by Postgres row-level security, not by convention — a missing WHERE clause returns nothing rather than somebody else's members.
Your data, only yours
Many venues live in one database. Isolation is enforced by Postgres row-level security, not by remembering to filter — because the one thing a venue will never forgive is seeing somebody else's members, and "we were careful" is not an architecture.
Each request takes one connection and runs inside one transaction, which is what carries the tenant identity. Get the query wrong and you get an empty result. You do not get another club's roster.
Platform administrators sign in against a different table from venue users, separated by token issuer. Without that, a venue administrator — who can create venue users — could grant themselves the ability to read every other venue. There is a test for exactly that, in both directions.
Enforced, not intended
Guarantees, not promises
The rules that would be most embarrassing to get wrong are the ones the handler is not trusted with. They live in the schema, and every one of them is exercised over HTTP by a verification script — because a constraint nobody has seen fire is a constraint that might not be there.
Two confirmed bookings can never overlap in the same room, sheet, court or lane. Enquiries may overlap, because two people may ask about the same Saturday — and the desk needs to see both before choosing.
A harness cannot be out with two people at once, however the desk is clicked. The same shape covers anything the venue lends: a rental locker, a set of rocks, a boat.
Exactly one current qualification per member per code, so a re-assessment replaces rather than stacks, and a revocation takes away the access it granted.
The table is computed from games rather than stored beside them, so correcting a scoresheet in March corrects the standings in the same breath. Nobody reruns anything.
Money
Stripe Connect direct charges: the money lands in the venue's own Stripe account, and the platform takes a commission on the way past. Onboarding is Stripe's, not ours — we never hold the venue's funds.
Stripe Checkout from the registration form, the bonspiel entry, the competition entry or the members' app. Commission is set per venue in the platform console.
Cash, cheque, e-transfer and card, recorded against the same invoice. A club that runs half its money through a shoebox is not a club that will switch.
A whole season or term billed at once, with memberships and programme places on one bill per member, and a treasurer's summary that reconciles.
Two things worth naming
Every platform has a couple of these. Ours are written down because they will bite anybody who reimplements this from scratch.
A course meeting Tuesday at seven was stored at three in the afternoon, and moved another hour when the clocks went back. Wall-clock times are now converted in the venue's timezone — not the server's, because one deployment serves venues in different provinces.
A request holds one connection inside one transaction, which is what makes row-level security work. A failed write marks the whole transaction aborted, and the handler's next statement dies pointing at the wrong line. Best-effort work gets a savepoint, or is deferred to just before the commit.
Questions we get asked
Yes. Many venues share one deployment and one database, isolated by Postgres row-level security rather than by convention — a missing WHERE clause returns nothing, not another venue's members. Platform logins are a separate table from venue logins.
Static HTML websites per venue, a React office console, an Expo / React Native members' app, and an Express API on Postgres with Stripe Connect, Kisi and Brivo integrations, plus JSON and iCal public feeds.
If it has a roster, a liability, a finite resource and a season, most of it is already built. The verticals page ranks candidates honestly by how much of the core they reuse; tell us what your venue does and we will say which column it lands in.
Next step
The quickest way through this is a walkthrough driven by real data — a season drawn, scheduled, scored, billed and broadcast, in about thirty minutes.
Book a walkthrough