Aquaworx

A swim school running entirely on manual processes — phone bookings, cash collection, paper attendance, spreadsheet scheduling — needed to move online without losing the operational details that keep a swim school running: instructor availability, lane capacity, age-gated programmes, and a fair way to handle missed classes. Off-the-shelf booking tools don't handle these rules well, so it needed to be purpose-built.

• A booking engine that validates swimmer age against programme requirements, checks live class capacity, and prevents overbooking with an atomic reservation model — pending bookings hold a seat for 15 minutes before automatically releasing it if payment isn't completed.
• A production payment integration with a regional card gateway (JMD currency), including a reconciliation safety net that re-checks the bank's side of a transaction before marking a payment expired, so a slow or missed webhook never costs a paid booking.
• Makeup-class logic that encodes the school's actual policy using machine-readable tags rather than trusting free-text cancellation reasons, so credit is granted reliably.
• A scheduling model where admins define recurring weekly templates once, and the system generates dated class instances on demand — with a database-level constraint that makes it physically impossible to double-book a lane.
• Dual check-in codes for attendance — a 4-digit code for verbal front-desk check-in and a hashed code for app-based lookup — feeding directly into no-show tracking and automatic makeup eligibility.

A live platform now running the school's actual bookings and payments — parents book and pay online, instructors manage their own schedules and attendance, and admin has full visibility without manual reconciliation.

• Two-tier database access — a row-level-security-scoped client for regular reads, with a separate service-role client reserved for trusted admin operations only.
• Payment reconciliation, not just payment processing — the integration actively re-verifies transaction status against the gateway to catch missed webhooks, the difference between a demo integration and one trusted with real revenue.
• Business rules encoded at the data layer, not just the UI — lane double-booking prevention is a database constraint, so it holds even if the app is bypassed.

Next.js 16 · React 19 · TypeScript · Supabase (Postgres, Auth, RLS) · Stripe · Oyster/Sagicor Mastercard Gateway · Tailwind CSS