Fitness · Booking & Membership Case study

EducoGym

A booking and membership platform for an appointment-based gym operating across thirteen locations, where members train in short supervised sessions rather than dropping in.

Fitness · Booking & Membership

EducoGym EducoGym

Full-Stack Engineering

System map · Scheduling lifecycle

Operational outcome

  • Manual operations → self-service Members run their own booking and membership requests
  • One portal for staff Slots, bookings and plans instead of by hand

Booking lifecycle

  1. Member

    One booking per member per day

  2. Availability

    Opening hours, slots and capacity

  3. Book or reschedule

    Against the day’s slots

  4. Workout slot

    Supervised, not open access

  5. Membership actions

    Pause, resume, plan change

Staff portal

  • Slot scheduling
  • Booking oversight
  • Membership approvals
  • Thirteen locations
Product surface
EducoGym booking and membership screens across mobile and desktop.

Engineering

Next.js · TypeScript · NestJS · Node.js · AWS

Public product · Described from public sources · Implementation not disclosed

Role
Full-Stack Engineering
Disclosure
Public product · Described from public sources · Implementation not disclosed
Links
Product website

The problem

What the system had to solve.

EducoGym trains people in short supervised sessions rather than open gym access, across thirteen locations. When the service is the appointment, the booking is not a convenience feature - it is the product. Running that on manual booking and membership admin puts a person between every member and every session.

What I owned

The responsibility behind the work.

Contributed to building the platform that moved those operations into a dedicated product: member booking, workout-slot management, membership administration and the staff portal behind them.

Publicly documented as replacing manual gym operations with online booking, workout-slot management, membership management and a full admin portal. Members book a slot per day against available gym hours and can request a membership pause; staff work from a portal covering transactions, trainee plans and booking monitoring.

Engineering approach

How it was built.

The domain problem in a system like this is agreement between three views of the same slot: what the member sees as available, what the schedule actually holds, and what an administrator has changed underneath. Bookings, reschedules, membership pauses and slot changes all move that state, and each has to leave the other two correct. Implementation detail beyond the publicly documented stack is not mine to publish.

Booking path

  1. Availability
  2. Slot booking
  3. Membership action
  4. Admin review

A gym that is not a gym

Why the usual booking model does not fit.

A conventional gym sells access. Members come when they like, and the software’s job is a door and a direct debit. This operating model is different: members train in short supervised sessions, which means every visit occupies a slot, a trainer and a place — and the business only works if those are allocated rather than assumed.

That turns membership software into scheduling software with a commercial model attached, across thirteen locations that each have their own hours.

What the model requires

  • Slots rather than open access
  • One booking per member per day
  • Availability resolved against each location’s hours
  • Supervision capacity, not just floor space
  • Membership state that can be paused

What is actually bookable

Availability is computed, not stored.

A member does not choose from a list of slots someone typed in. What is bookable is derived: the gym’s opening hours for that day, the workout slots configured against them, what is already taken, and whether this member has already used their booking for the day.

Resolving a booking

  1. Location and date
  2. Opening hours for that day
  3. Configured workout slots
  4. Remaining capacity
  5. Member’s daily entitlement
  6. Bookable slots
Each condition can independently make a slot unbookable, so all of them are evaluated before a place is offered rather than after it is chosen.

The one-per-day rule is a business rule with a scheduling consequence. It has to be enforced where the booking is made, not checked afterwards by staff looking at a list.

Membership that can be paused

A state machine, not a boolean.

Members go on holiday, get injured, and travel for work. Without a way to pause, the only options are paying for nothing or cancelling — and cancelling is the one the business cannot afford. A pause request is bounded, reviewable, and has consequences for both billing and booking eligibility.

Membership states

  1. Active membership
  2. Pause requested
    1. Approved Bounded period
    2. Booking suspended
    3. Resumes automatically
    1. Declined
    2. Membership continues
Pause is bounded rather than indefinite, which is what makes it a supported state rather than an exception staff manage by hand.

The portal staff actually run the business from

Replacing the operations that used to be manual.

The work replaced a manual operation, which means the measure of it is not the member app but whether staff can run a location without falling back to paper. The portal covers what they previously did by hand: configuring slots, watching bookings, managing trainee plans and seeing transactions.

Staff surface

Scheduling

  • Workout-slot configuration
  • Booking monitoring
  • Capacity per location

Members

  • Trainee plans
  • Membership and pause requests
  • Transactions

Oversight

  • Analytics and booking dashboard

Thirteen locations is the number that makes this necessary. One location can be run from a diary; thirteen cannot be run consistently without a system that holds the same rules everywhere.

Engineering scope

What I worked on.

  1. Member booking against available workout slots
  2. One slot per day, resolved against the gym’s open hours
  3. Membership pause requests of up to four weeks
  4. Workout-slot and booking administration
  5. Trainee plans and transaction views for staff
  6. Analytics and booking dashboard
  7. Online payments

Why these decisions mattered

The trade-offs behind the platform.

  • Slots, not open access

    Decision
    Every visit is a booked slot against configured availability.
    Why
    Supervised training consumes a trainer and a place; those have to be allocated, not assumed.

  • Availability derived at request time

    Decision
    Bookable slots are computed from hours, configuration, capacity and entitlement.
    Why
    A stored list of slots drifts from the gym’s actual hours the first time they change.

  • Pause as a first-class state

    Decision
    Bounded, reviewable membership pauses.
    Why
    The alternative to pausing is cancelling, and cancellations do not come back.

  • One portal for staff

    Decision
    Slots, bookings, plans and transactions in one place.
    Why
    The work replaced a manual operation; partial coverage means staff keep the paper system too.

Product surface

Who uses it, against the same model.

Member
Browsing availability, booking a daily slot and requesting a membership pause
Operations
Workout-slot management and booking administration
Administration
Trainee plans, transactions and the booking dashboard

Impact

What the product replaced.

The result was a digital operating layer for appointment-based training: members manage their own booking and membership requests, and staff run slots, bookings and plans from one portal instead of by hand.

Technology

The technical surface.

  • Next.js
  • TypeScript
  • Node.js
  • NestJS
  • AWS

Next: VanGo

Back to all work Start a conversation