// the take
Gymie is a Laravel 13 + Filament 5 admin application for running a gym or fitness club: members, subscriptions, plans, invoices, expenses, and a sales-enquiry CRM pipeline. It's aimed at small-to-mid fitness businesses or agencies that want a sellable, self-hostable gym management product rather than developers needing a library.
The JSON API is unusually well structured for a project this size — versioned under /api/v1, Sanctum bearer auth, and per-resource Schema classes that define allowlisted sortable/searchable/includable fields instead of letting arbitrary query params touch the DB. It covers the full operational loop a gym actually needs: enquiries with follow-ups, plan-based subscriptions, invoices with transactions, and expense tracking, not just a member list with a paywall bolted on. Authorization is handled through a real Policy per resource plus a permissions package (Shield/spatie), so role-based access isn't an afterthought.
There's no payment gateway integration anywhere in the stack — invoices and transactions look like they're recorded manually, so collecting actual online payments from members is left entirely to the adopter. The presence of a NullTenantContext/TenantContext contract with no real implementation suggests this is single-tenant per install; anyone wanting to run it as a SaaS for multiple gyms has to build tenant isolation themselves. Production use requires a queue worker and the Laravel scheduler running continuously just to mark overdue invoices and update subscription statuses — that's real ongoing ops burden for what's pitched as a drop-in business app, not just a web server. The project leans on the nnjeim/world seeder for country/state/city data, which the README itself flags as slow and memory-hungry enough to need a php.ini bump and selective seeding advice — a sign the country-data dependency is heavier than the app needs.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →