Activa

The operating system for active-life businesses.
ARCH v0.1DATE 2026-08-31 DB Supabase · Postgres 17 · ap-southeast-1 STATUS P1 LIVE — 24 tables · 57 policies · advisors clean
What it is

One platform for any business built on members, spaces and sessions

Activa is the generic sibling of Setpoint. Setpoint runs padel clubs; Activa runs gyms, recovery centres, wellness studios, multi-sport clubs and lifestyle destinations — anything with members, bookable spaces, appointments and events. It replicates Setpoint's proven mechanics under generic nouns, and adds the two structures Setpoint never needed: an organisation above the venue and operators below it.

Two real customers shaped the model: 24 BLVD (one brand, seven venues on Sukhumvit 24, members + events + tickets) and the Sterling-class wellness centre (one address: padel, pickleball, tennis, barre, Muay Thai — plus a recovery clinic run by a partner business).

Tenancy

Org → Venue → Resource, with Operators alongside

orgthe tenant · billing & membership boundary · RLS boundary“24 BLVD” · “Sterling”
↓
venuea physical location“House of Savoy” · “LULU” · “Sukhumvit 24”
↓
resourcea bookable space or assetcourt · studio · treatment room · ice bath · table
 
operatorsub-tenant business inside the org — own services, providers, payouts; the org sees everything“Form Recovery”

Every row-level record carries org_id — that is the isolation wall. venue_id narrows within it. Membership lives at org level: one 24 BLVD membership opens all seven venues.

Lineage

The Setpoint → Activa noun map

SetpointActivaWhat changed
facilities→orgs + venuesbrand split from location; multi-venue native
courts→resourcesresource_type + activity_tags[], no sport baked in
bookings→bookingssame hold → confirm lifecycle, DB-level overlap guard
classes + lessons→services + appointmentsthe offering vs. the scheduled instance
coaches→providerscoach, trainer, therapist, instructor
membership_plans / user_memberships→plans / membershipsorg-level, not per-venue
club_credits→credits + ledgersame minor-unit ledger
user_facility_roles→user_org_rolessame pattern, venue/operator scope columns
customers→membersorg-scoped profile over shared auth
— none —+events + tickets24 BLVD's core loop, first-class
— none —+operatorsSterling's partner businesses, first-class
Decisions

Proven mechanics kept, deliberate departures

replicated from Setpoint

  • Hold → confirm lifecycle — held (5-min TTL) → confirmed → completed / cancelled / no_show
  • Money in minor units — satang/cents integers, convert at display only
  • RLS pattern — one user_org_role() helper + per-table role policies
  • Passwordless auth — Supabase OTP / magic link
  • Pricing cascade — special-date → resource → type → org default (P2)
  • Webhooks from day one — protocol-ready without schema surgery

new in Activa

  • Org above venue — Setpoint's single-level tenancy was its ceiling
  • Operators — a partner clinic is a different business, modelled as one
  • Events + ticketing native — typed events, RSVP or ticketed, per venue
  • Members self-serve — B2C members join through the app; staff stay invite-only
  • Zero sport assumptions — activity lives in tags, not enums
  • Overlap guard in the DB — GiST exclusion constraint, not just RPC discipline
Schema

24 tables in six domains

Tenancy

orgsvenuesoperatorsresourcesresource_schedules

People

user_org_rolesmembersproviders

Membership

plansmembershipscreditscredit_transactions

Scheduling

bookingsservicesappointmentsappointment_attendees

Events

eventsevent_tickets

Platform

paymentswaiverswaiver_signaturesapi_keyswebhook_subscriptionswebhook_deliveries

Roles ladder — write access narrows as you go right; members see only their own rows:

owneradminmanager providerstaffoperator_adminmemberguest

Published events are publicly readable — the member-app feed needs no session to render.

Roadmap

Three phases

Phase 1 · shippedLIVE

Core schema

  • Full tenancy + RLS
  • Members, plans, credits
  • Bookings + appointments
  • Events + tickets
  • 24 BLVD org + 7 venues seeded
  • Security advisors: clean
Phase 2 · next

Mechanics + API

  • Hold/confirm RPCs
  • Pricing rules cascade
  • Provider availability
  • Packages, promo codes
  • Public API v1 (/orgs/{slug}, /me)
Phase 3 · later

Scale-out

  • Operator payout splits
  • Programs / cohorts
  • POS-lite
  • Open protocol surface
  • Second customer onboarding
Open questions (with Alba, 24 BLVD)
  1. Does the member QR gate entry at the door, or only identify at reception?
  2. Ticketed events: Stripe from day one, or RSVP-only at launch?