Web project

Athletica Roll Call

One platform running an outdoor fitness business end to end — bookings, coaching, nutrition, a shop, Stripe billing, and the marketing site.

Client: Athletica — outdoor group fitness, Adelaide
Role: Sole developer
Scope: Member, instructor & admin app + marketing site
Timeline: Jan 2026 – ongoing
Status: Active development

// overview

Athletica is an outdoor group-fitness company running bootcamp-style sessions across multiple locations in Adelaide. They were coordinating members, attendance, rosters and payments across spreadsheets and messaging apps.

I built a single platform to replace all of it. Members sign in to book sessions against their membership entitlements, follow assigned meal plans, log measurements and photos through a structured six-week challenge, and buy merchandise. Instructors run live roll call, build sessions from an exercise library, and track attendance. Admins manage memberships and pricing, staff and rosters, shop inventory and orders, and a tiered permission system that controls who can see what.

Payments run on Stripe — recurring memberships, prepaid terms, session packs and shop orders — with a webhook-driven model where entitlements are only ever granted after Stripe confirms the money settled.

The public marketing site is served from the same application, pulling coaches, locations, session times and live pricing straight from the admin database, so it cannot drift out of date.

Scale

~44k

Lines of TypeScript / TSX

119

React components

45

Database tables & views

17

SQL migrations

6

Serverless API endpoints

6

Permission role levels

// what it does

Key features

Session booking & roll call

Members book against their membership entitlement
Instructors run live roll call and mark attendance
Capacity, session times and locations are all admin-managed
Monthly calendar view with book-all and unbook-all actions

Membership & billing

Three membership tiers across monthly, 6-month and 12-month terms
Weekly, fortnightly and 4-weekly billing options
Session packs and casual sessions alongside subscriptions
Self-service membership pausing with a minimum duration

Six Week Challenge

A structured transformation program with measurements and progress photos
Check-ins and milestones
Assigned meal plans per participant
A coach-facing view of each participant

Nutrition system

Ingredient database with per-unit macro tracking (per 100 g, per biscuit, per egg)
Recipe builder that calculates macros automatically
Meal plan assembly and generated shopping lists
Bulk CSV import for ingredients and recipes

Workouts, shop & community

Exercise library with media, used to compose sessions and assign them to programs
Product catalogue, cart, discount codes and Stripe checkout
Order management
Groups, messaging, announcements, events and an activity-points system

Permissions & the public site

Six role levels from member through to critical admin
Admin impersonation for support, plus two-factor authentication
An animated, responsive marketing site — home, memberships, locations, about, FAQ, contact and legal
Coaches, locations, session times and pricing pulled live from the database

// engineering

The hard parts

The problems that shaped the architecture, and how each one was solved.

01

Payments where the browser has no authority

Nothing in the frontend can grant a membership or add session credits. The browser sends only a plan code, never an amount — prices are always looked up server-side, so a tampered request cannot buy a 20-pack for a dollar. Entitlements are written by a single Stripe webhook, only after Stripe confirms the payment settled. Every webhook event ID is recorded before any work happens, so Stripe’s at-least-once delivery cannot hand out the same session pack twice.

02

Security enforced in the database, not the UI

Access rules live in PostgreSQL Row Level Security policies, so they hold regardless of what the client sends. Anonymous visitors read purpose-built views that expose only public columns, keeping internal notes out of reach of the marketing site.

03

One codebase, two audiences

The marketing site and the application share a database but not a bundle — the public site is code-split, so someone reading the pricing page never downloads the admin application.

04

Accessibility built into the motion work

Every animation on the public site collapses to its finished state when a visitor has asked for reduced motion, including background video, which falls back to a still.

// stack