Memberships, check-in, billing and trainer scheduling in one system — with the freeze, grace and pro-rata rules that cause every front-desk argument handled explicitly.
public/images/solutions/gym-front-desk.pngThe front-desk screen. Membership state, days remaining and any outstanding balance visible before the receptionist has to say anything.
Who it's for
Single-location gyms and small chains, plus studios running class-based or personal-training models. The threshold where spreadsheets stop working is usually the first month somebody's membership is disputed and nobody can prove when it was frozen.
The problem
In the words operators use, not the words software vendors use.
Renewal is the entire business model, and in most gyms it depends on a receptionist noticing a date in a spreadsheet. Members lapse quietly, and the first sign is that they stopped coming two months ago.
A member travels for three weeks and asks for their membership to be paused. Whether that extends the end date, whether it counts against an annual freeze allowance, and whether it was actually approved are all questions with no recorded answer — so the argument is won by whoever is more insistent.
Different staff quote different prices for the same thing. Cash taken at the desk does not always reach a record. The daily close does not reconcile, and by the end of the month nobody tries.
Attendance is the strongest predictor of whether a member will renew, and most gyms do not capture it at all — which means retention work is guesswork rather than targeted at the people who have stopped coming.
Sessions sold, sessions delivered, sessions remaining — held in a notebook, and disputed at exactly the moment the package runs out.
What it does
Feature lists organised by technical module tell you nothing about whether the software fits your team. These are grouped by the person who lives in them.
Plans are configuration, not code, so seasonal offers and corporate rates do not require a developer.
Everything about a member on one screen, including the things that matter at the desk rather than in a report.
The highest-frequency interaction in the building. It has to be fast, and it has to keep working when the internet does not.
The part that generates disputes. Every rule here is explicit, configurable and logged.
For gyms where classes are the product rather than an extra.
Session-level accounting for the highest-margin product in the building.
Attendance data is only worth capturing if something acts on it.
A cash-drawer workflow, because the alternative is a monthly reconciliation nobody completes.
Screenshots
Every screenshot uses generated demo data. No real customer, student or member record appears anywhere on this site.
public/images/solutions/gym-membership-states.pngA membership with its full state history — including the freeze that was approved in March and the seven days it added to the end date.
public/images/solutions/gym-checkin.pngCheck-in. Photo, state and days remaining — enough for the receptionist to handle a renewal conversation without opening another screen.
public/images/solutions/gym-freeze-request.pngA freeze request. The annual allowance is enforced by the system, which removes the argument from the front desk entirely.
public/images/solutions/gym-daily-close.pngDaily close with a variance flagged at the point it occurred, rather than discovered at month end.
public/images/solutions/gym-retention.pngThe at-risk list. Ranked by attendance decline rather than expiry date, because the members worth calling are the ones who stopped coming before they stopped paying.
Roles & permissions
Publishing this table is unusual. It is also the fastest way to show that the system was designed for a real deployment rather than for a demo.
Three roles cover almost every gym. The distinction that matters most is between what a receptionist can do at the desk and what requires a manager — because that boundary is where money goes missing.
| Capability | Owner All locations | Manager Assigned location | Receptionist Assigned location | Trainer Own members |
|---|---|---|---|---|
| Member records | Owner: Full | Manager: Full | Receptionist: Edit | Trainer: View |
| Register a new member | Owner: Full | Manager: Full | Receptionist: Edit | Trainer: — |
| Check members in | Owner: Full | Manager: Full | Receptionist: Full | Trainer: Edit |
| Take payment and issue a receipt | Owner: Full | Manager: Full | Receptionist: Full | Trainer: — |
| Apply a discount | Owner: Full | Manager: Approve | Receptionist: — | Trainer: — |
| Approve a freeze | Owner: Full | Manager: Approve | Receptionist: — | Trainer: — |
| Process a refund or cancellation | Owner: Approve | Manager: Approve | Receptionist: — | Trainer: — |
| Edit a completed transaction | Owner: — | Manager: — | Receptionist: — | Trainer: — |
| Plan and pricing setup | Owner: Full | Manager: View | Receptionist: — | Trainer: — |
| Class timetable | Owner: Full | Manager: Edit | Receptionist: View | Trainer: View |
| PT package sessions | Owner: Full | Manager: Edit | Receptionist: View | Trainer: Own |
| Daily close | Owner: View | Manager: Approve | Receptionist: Edit | Trainer: — |
| Financial reports | Owner: Full | Manager: View | Receptionist: — | Trainer: — |
| Retention analytics | Owner: Full | Manager: Full | Receptionist: — | Trainer: Own |
| Staff and role management | Owner: Full | Manager: — | Receptionist: — | Trainer: — |
| Audit log | Owner: View | Manager: — | Receptionist: — | Trainer: — |
Technical architecture
Skip this section if you are not technical — nothing later depends on it.
An ASP.NET Core API over PostgreSQL, with a React front-desk application built as an offline-capable PWA. The membership state machine is implemented as an explicit, tested transition table rather than as a set of boolean columns — that single decision is what makes the billing edge cases tractable.
Clients
Application
Async work
Data
Strong typing on a domain full of money and dates, and a state machine that benefits from exhaustive compile-time checking.
Memberships are a temporal, transactional problem. Range types and exclusion constraints do real work here.
Check-in must survive an internet outage. A PWA with a local queue is the least fragile way to do that.
Members will not install a native app for a single gym. A fast web app they can add to their home screen gets used.
Renewal invoices, expiry transitions and at-risk detection are scheduled work that must be inspectable and re-runnable.
Gyms have existing hardware. Replacing it is usually a deal-breaker.
Renewal reminders are the highest-ROI message the business sends.
Single-tenant per gym or chain, deployed to a small VM or managed container host. The front-desk PWA runs on ordinary desktop hardware. Chains run one deployment with location-scoped access and consolidated reporting for the owner.
Notable engineering decisions
This is the section that separates a system somebody built from a system somebody screenshotted.
Most gym software models membership status as a set of columns — is_active,
is_frozen, expiry_date — and derives the member’s status by evaluating them together
at read time. It works until two of them disagree, which happens the first time somebody
freezes a membership that was already in its grace period.
We model it as an explicit state machine with six states:
Pending → Active → Expiring → Grace → Expired → Cancelled
↕
FrozenEvery transition is a row: from-state, to-state, reason, actor, timestamp, and the effect it had on the end date. The current state is a column, but it is derived from the transition history and reconcilable against it — so if the two ever disagree, that is a detectable bug rather than an invisible one.
The properties this buys are worth the extra table:
Cancelled to Frozen. The check
lives in one place instead of being re-implemented at every call site.The Expiring and Grace states exist because gyms treat them differently and both need
distinct access rules. Expiring is still fully active but triggers renewal messaging;
Grace is past the end date but still admitted, with configurable behaviour — some gyms
allow full access for seven days, others allow entry but block classes.
The list of cases that a naive implementation gets wrong is long enough that we treat it as the acceptance-test suite rather than as an afterthought:
Every one of these is expressible as an ordered sequence of transitions plus a pro-rata calculation, and every calculation is stored with its inputs on the invoice line — day count, daily rate, days used, days credited — not just its result.
That decision costs a little storage and settles almost every dispute at the desk in under thirty seconds. It is the single highest-leverage thing in the billing module, and it is the thing that off-the-shelf gym software most consistently does not do.
A gym’s front desk cannot stop working because a fibre line was cut. But an offline-capable check-in is not simply “cache the member list” — the hard part is what happens when the connection comes back.
The front-desk application is a PWA holding a locally-cached snapshot of active memberships, refreshed continuously while online. When the connection drops it keeps admitting members from that snapshot and queues each check-in locally with a client-generated idempotency key.
On reconnect, the queue replays. The idempotency key means a replayed check-in that already reached the server is a no-op rather than a duplicate. Conflicts — a member who was cancelled server-side during the outage but admitted from the stale snapshot — are surfaced as a reviewable list rather than silently resolved in either direction, because both possible resolutions are wrong some of the time and only a human knows which.
Payments deliberately do not work this way. An offline payment is recorded as pending and confirmed on reconnect; the receipt is not issued until the server has it. Taking money into a queue that might fail to sync is how you end up with a member holding a receipt for a payment the system has no record of.
A seeded demo environment is available during a call. Every member name, photo placeholder and payment record in it is generated — no real member data appears in any demo or screenshot.
Plans, pricing and freeze policy are configuration and need no development. What usually does need work is hardware integration — turnstiles and biometric readers vary enormously — so we confirm your exact models during discovery rather than after.
FAQ
Check-in continues. The front-desk application holds a local copy of the active membership list and queues check-ins in IndexedDB, so members keep getting through the turnstile. When the connection returns, the queue syncs with idempotency keys so nothing is double-recorded. Payments are the exception — those are held as pending and confirmed on reconnect, because taking money offline without a receipt is a dispute waiting to happen.
That is a policy decision, and the system supports either. Most gyms route freeze requests through an approval step, because self-service freezing without a cap is how an annual membership quietly becomes an eighteen-month one. The annual allowance and maximum duration are both configurable, and both are enforced rather than advisory.
Usually, but the honest answer depends on the model. Most access-control hardware exposes either an SDK, a local HTTP interface, or a database we can read. We confirm yours during discovery and tell you before you commit if it is one of the closed ones that would need replacing.
The unused portion of the current plan is credited pro-rata, the new plan is charged from the change date, and both calculations are stored on the resulting invoice — not just their net result. When the member asks why they were charged that amount, the receptionist can show them the working.
Yes. Staff are scoped to their location, members can be given all-branch or single-branch access as a plan attribute, and the owner sees consolidated reporting. Cross-branch check-in is recorded against the branch where it happened.
Related
Operational systems built around how your business actually works — not around what an off-the-shelf product assumes.
Learn moreLegacy .NET applications and databases brought back under control — incrementally, without a rewrite that stops the business for a year.
Learn moreWe will show you the working system, tell you honestly what would need changing for your operation, and give you a range before you commit to anything.
30 minutes · We reply within one business day.