GymFlowGymFlow

GymFlow replaces that stack with one multi-tenant application, and deliberately ships two surfaces rather than one. Owners get a console covering members, payments, dues, attendance, inventory and workout programs. Members get their own progressive web app for membership status, workouts, progress and rewards. Renewal chasing — the job owners most want to stop doing — is automated over WhatsApp.

• One relational model spanning members, plans, payments, dues and attendance
• Each gym is a tenant with its data isolated at the database layer
• A second product surface: a member PWA with gamified rewards
• Attendance captured as self-service, so it costs the front desk nothing
• WhatsApp automation for expiry and dues reminders
• GymFlow sells itself: owner subscriptions with a 14-day trial and three tiers

• Members — roster with plan, expiry and status, searchable by name, phone or member ID, with CSV import and export
• Onboarding — a two-step wizard that suggests the next member ID and validates availability as you type
• Payments — collection split by cash, UPI and card, separated into memberships, inventory and dues, over any date range
• Dues — outstanding fee tracking with per-member balances and reminder actions
• Attendance — a kiosk screen members operate themselves, with morning and evening sessions and a daily check-in count
• Inventory — stock and supplement sales that feed the same collection totals
• Programs — reusable workout templates with draft and published states, assignable to members
• Member App — portal access control, invitations, gamification, and weekly and monthly active counts
• Subscription — GymFlow's own billing across monthly, six-month and yearly tiers behind a trial
• Daily report PDF, light and dark themes, and a responsive layout for running the floor from a phone

Two clients and a kiosk talk to one Next.js application. Middleware resolves the session and the tenant before a request reaches a route handler, authorisation is applied in a single policy layer, and Postgres row level security acts as the backstop. Supabase supplies auth, Postgres and storage; WhatsApp sits behind the service boundary.

The decisions that mattered were mostly about where to put trust, and how much the front desk should have to do. Anything security-relevant resolves on the server and is re-checked in the database; anything routine is designed to need no staff attention at all.

• Tenant id is derived from the session, never read from the request body
• Row level security policies mirror the application's role rules, so a mistake in a query cannot leak another gym's data
• Money is stored in integer minor units, so cash, UPI and card totals reconcile exactly
• Attendance writes are idempotent per member per session, so a double tap at the kiosk cannot inflate the count
• Member IDs are human-readable and sequential per tenant, with availability checked live during onboarding
• Reminder sweeps are scheduled and idempotent, so a retry cannot message the same member twice
• Dashboard counters are computed in SQL against indexes on tenant and date rather than aggregated in JavaScript
• Every mutation boundary is schema-validated before it reaches the database

GymFlow is live and selling. The marketing site is at gymflow.sbs and the product runs at app.gymflow.sbs, with eight shipped modules across an owner console and a member PWA, a 14-day trial, and three subscription tiers. It is the project where I own every layer — schema, authorisation, billing, deployment and the pricing page — rather than just the features.

Two things I would do differently. Write the row level security policies alongside the schema rather than after the features, because retrofitting them meant re-testing every read path. And model money as an append-only ledger from the first commit — I arrived there, but only after the mutable version had produced balances I could not explain. The broader lesson was about adoption: the attendance module only started producing data once I stopped asking staff to operate it.