Multi-tenant SaaS gym management platform built for the Nigerian market
80+
Gyms onboarded
3,500+
Members managed
~30%
Free-to-paid conversion
4
Subscription tiers
SaaSMulti-tenantFintechNigeriaCRMPWA
Homepage
The Problem
Nigerian gyms were running on paper. Member records lived in notebooks, payments were cash-only, and attendance was not tracked at all. No affordable system existed that worked on shared hosting, handled local payment rails, and could be set up by a non-technical gym owner without documentation or a setup call.
Overview
GymProHub is a gym management SaaS platform built specifically for Nigerian gyms. A gym owner signs up and gets a complete operations platform: member management, attendance tracking, membership plans, payment collection, staff management, class scheduling, analytics, and a self-service member portal. The platform is multi-tenant and every record is scoped by gym_id.
Four subscription tiers serve gyms from solo operators to enterprise chains. Free gives 20 members and 1 staff account with the platform watermark visible and ads shown. Core adds 100 members, 3 staff, role-based access control, audit logs, and SMS quota. Portal adds 300 members, 5 staff, a self-service member portal at a slug-based subdomain, class scheduling, inventory tracking, and white-label branding. Enterprise is unlimited members and staff, plus REST API access with webhooks, custom domain support, SSO, and a dedicated account manager.
Every gym gets its own Paystack subaccount. Members pay into the gym's subaccount and settlement goes directly to the gym's bank account. The platform takes a commission at the transaction level.
My Role
Defined the product strategy and architecture: multi-tenant model, subscription tier structure, feature gating logic, and the overall gym management workflow
Specified what sits at each pricing tier and why: Free is genuinely usable to prove value, Core adds the operational features gyms need at scale, Portal adds the member-facing experience, Enterprise adds automation and integration
Designed the per-gym Paystack subaccount model: gyms receive payments directly into their own bank accounts rather than waiting for a manual payout from the platform
Designed the QR check-in flow for walk-in day-pass payments: no staff involvement, no account required from the visitor
Defined the white-label branding system for Portal and above: custom logo, colours, CSS injection, and hidden GymProHub branding
Specified the staff permission model: gym owner, trainer, and receptionist each have different access scopes, configurable at the RBAC level
Designed the PWA offline strategy: operations queue locally and sync to the server on reconnect, so check-in works even when connectivity drops
Stakeholders
Gym owners (primary buyers)
Gym members (end users)
Gym staff (daily operators)
Paystack (payment partner)
SMS gateway providers (Termii, Africa's Talking)
Technical Context
Single codebase, single database, every table scoped by gym_id. The stack is PHP 8+ with PDO and MySQL 8, no framework, Apache with .htaccess routing. This keeps the stack lean and deployable on standard shared hosting without a build pipeline, which is important for the target market.
Paystack integration uses a per-gym subaccount model. When a gym owner sets up payment settings, the platform calls the Paystack API to create a subaccount linked to their bank account. From that point, all member payments go into the subaccount with a commission split at the transaction level.
SMS uses Termii as the primary gateway with Africa's Talking, SMSLive247, and BulkSMS Nigeria as alternatives. The member portal (Portal+ tier) is accessible at a slug-based subdomain. The PWA service worker caches member and plan data locally. Enterprise API endpoints authenticate via SHA256-hashed API keys with rate limiting and full audit logging.
Key Decisions
Per-gym Paystack subaccounts instead of a platform wallet
The alternative was to collect all gym revenue into a platform wallet and run manual payouts. Per-gym subaccounts delegate all of that to Paystack: each gym gets direct settlement into their own bank account, and the platform takes a commission split at the transaction level.
QR check-in for walk-ins with self-serve Paystack payment
Walk-in day-pass customers were previously handled manually: a staff member would create a temporary record, take payment however they could, and mark it done. The QR check-in page replaced this entirely.
PHP without a framework for deployment simplicity
The target customer is a Nigerian gym owner, most of whom are on shared Namecheap or cPanel hosting. Plain PHP with PDO means the app deploys by uploading files.
Free tier that is genuinely usable, not crippled
Free on GymProHub supports 20 members and 1 staff account with full core functionality. Small gyms can run on it indefinitely. Gyms that outgrow Free have already seen the value, so the upgrade is a continuation rather than a gamble.
PWA offline support as a baseline requirement
Nigerian gym staff cannot rely on consistent internet connectivity. The PWA caches what it needs, queues operations locally, and syncs when the connection returns.
Challenges
Building a product that works for gyms that have nothing digital yet
A lot of the gyms that signed up had no existing system. The product had to be simple enough that a gym owner with no technical background could set it up, add members, and see value within a single session.
Per-tenant configuration without a schema migration per gym
Each gym has different payment methods, SMS preferences, branding, Paystack credentials, and KYC requirements. Storing all of this without creating a migration every time a new configuration option was added required flexible configuration columns.
Offline sync without conflict resolution complexity
When staff operate offline, they queue check-ins, payments, and member updates locally. When connectivity returns, those operations need to sync without creating duplicate records or overwriting data that changed server-side.
Discovery
The opportunity was visible without formal research. Nigeria has a growing gym culture, particularly in Lagos and Abuja, and the management infrastructure had not kept up with it. Gym owners were running on paper: attendance in notebooks, membership payments in cash, member records nowhere. No affordable system existed that worked on shared hosting, handled local payment rails, and could be set up by a non-technical gym owner without support.
Stakeholder Friction
The one area of genuine friction was around the free tier limits. The initial thinking was to make the free tier quite restricted to push earlier conversion. The counter-argument was that a free tier designed to frustrate produces churn rather than upgrades. The current free tier, supporting 20 members and full core functionality, reflects the second position.
Outcomes
80+ gyms onboarded, ~30% converting to paid tiers
Over 80 gyms signed up across Free, Core, Portal, and Enterprise tiers, with approximately 30% converting from Free to a paid plan as they grew past the member limits.
3,500+ gym members managed across the platform
The platform manages member records, attendance history, and payment tracking for over 3,500 gym members across all active tenants, with full gym_id-level data isolation between each gym.
Walk-in admin eliminated at onboarded gyms
The QR check-in flow removed the manual day-pass process entirely at every gym using it. Visitor scans, selects plan, pays, and access is granted with no staff involvement.
Technology Decisions
PHP 8+MySQL 8Paystack SubaccountsTermii SMSAfrica's TalkingPHPMailerchillerlan/php-qrcodePWA Service WorkerApache + .htaccess
What I'd Change
I would have moved the member portal feature to the Core tier rather than the Portal tier. Gym owners on Core regularly ask for a way to let their members check their own attendance records and plan status. The Portal tier threshold was commercially reasonable, but in practice it locked a feature behind a paywall that would have reduced daily staff workload for the majority of gyms on Core.