The counter, the ledger and the turnstile, behind one login.

An operator-facing administration system for multi-branch gyms. Twenty-seven operator pages cover memberships, billing, attendance and staff, and the physical entry hardware reports into the same database rather than into a spreadsheet beside it.

The hard part is not the forms. It is that three different things write to the same records, on three different schedules, and none of them can be trusted to arrive in order.

• Every branch has its own members, staff and pricing, so nothing can be scoped globally.
• Attendance is written by fingerprint and face-recognition terminals that push to the server on their own initiative, not by a person clicking save.
• Front-desk staff, trainers and owners each need a different slice of the same screens.
• Renewals and trial expiries have to be chased on a schedule, without ever mailing the same person twice in a day.

One PHP application with three entry points into the same data: the operator pages, a device receiver, and scheduled jobs.

• A receiver implements the terminals’ own push protocol, identifying which branch a scan belongs to by the device serial number that sent it.
• A separate client module talks to the face-recognition devices for enrolment and entry logging.
• Access is gated per capability rather than per role, checked at the top of each page before anything renders.
• Trainers get their own portal and their own oversight views, rather than a filtered copy of the admin.
• Two scheduled jobs poll the devices and send renewal and trial-expiry mail, each guarded so a re-run on the same day cannot double-send.

1. 01

   Records first

   Members, branches, staff and pricing came before anything clever. The system is legible as a records application before it is anything else.

2. 02

   Billing grew one rule at a time

   Seven of the twelve migrations are payment rules — admission fees, discounts and discount types, split payments, validity periods, trainer-only fees. The billing model was not designed up front; it was extended as each real case appeared.

3. 03

   Hardware last

   Device integration arrived after the records were stable: raw scan storage, then entry and exit pairing, then access denials. Three separate migrations, in that order.

4. 04

   Permissions once there were enough people

   Staff permissions and the trainer portal are the newest migrations. The access model was added when the number of distinct roles made it necessary, not before.

PHP

Operator pages, the device receiver and the scheduled jobs

MySQL

Records and twelve tracked schema migrations

JavaScript

In-page interaction on the operator screens

CSS

The interface, without a framework

No outcome for this project has been verified. There is no measurement, export or client statement behind it, so nothing is claimed here — an empty result is the accurate one, not a placeholder for a number to be filled in later.

• The project source tree: 27 operator pages and the trainer-portal module
• The sql/ directory: 12 named schema migrations
• The device receiver implementing the terminals’ push protocol
• The scheduled reminder job, whose own header documents its once-per-day guard