MGR

Multi-tenancy that stayed simple on purpose

Row-level isolation on a single tenant column, applied through one concern included in 114 of the 248 models. No schema-per-tenant, no database-per-tenant, no Apartment or acts_as_tenant. That is a deliberate choice rather than a shortcut, and the part that makes it defensible is where tenant resolution happens.

A Rack middleware runs before any controller and resolves the tenant from the request origin, falling back to a custom-domain lookup for studios on their own hostname, and to an explicit parameter for mobile and partner clients that have no browser origin. Controllers never resolve a tenant; they read one that has already been established. The same concern validates that associated records belong to the same tenant, so a cross-tenant reference fails at the model layer instead of quietly leaking. That check is the answer to "how do you know a query never crosses tenants".

One authorization model across every surface

Every business operation in the system is a command object - 745 of them across around 98 domain folders - and each one declares the actor types and permissions allowed to run it. The check-in iPad, the member's phone, the admin console and the partner API all enter through the same door.

The practical consequence is that adding a seventh surface does not mean re-auditing permissions across a controller layer. It means issuing a token with the right actor type. Commands compose, emit activity-log entries as a side effect, and return validation failures as structured data rather than exceptions, so every client renders the same errors the same way.

The money model, and the vocabulary underneath it

Void versus refund, suspensions that shift future billing, unpaid visits carried as debt, proration, account balances, gift card instances, promotions that re-apply on renewal, per-location sales tax, late-cancel and no-show penalties, payment method migration, and a revenue ledger that has to reconcile against all of it. 165 tables and 466 migrations is what that costs.

A large part of the work here was not code but vocabulary: an internal domain document runs to a couple of hundred lines of "these two words mean the same thing" and "these two things sound identical and are not". That document is now also what the in-app assistant retrieves from, which is the cheapest possible return on having written it down.

Asynchronous work, and real time without ActionCable

192 background workers, 95 of them dedicated to notifications, and 46 scheduled jobs that run the parts of the business that must happen whether or not anyone is logged in: package renewals, booking reminders, suspension expiry, email suppression checks, revenue computation.

Real-time updates go over server-sent events on Redis pub/sub rather than ActionCable - one connection per session, namespaced per tenant and per receiver, fanned out to an in-app pub/sub on the client. Reservations, orders, conversations, typing indicators, notifications and reviews all ride the same channel.

Where customers author their own automation, the system uses event sourcing: domain events publish to global, per-user and per-tenant streams, and a subscriber drives the workflow engine. It is event-sourced only there, where a stable public event vocabulary genuinely earns its complexity.

Search, and retrieval for the assistant

Elasticsearch indexes 19 models to power a single global search across clients, staff, schedules, packages, retail products, gift cards and promotions - the search in the screenshots above.

Alongside it, pgvector holds 1,536-dimension embeddings of the product's own support documentation, chunked and indexed so the assistant answers from what the product actually does rather than from what a model assumes fitness software does.

Two AI products, shipped into a live system

The first generates notification templates: a studio brands all 114 of its transactional messages in under half an hour instead of hand-editing 82 emails, with validated LLM output, a bounded repair loop, and a drafts table so nothing goes live without a human approving it. There is a full write-up of that work, including the failure modes.

The second is a multi-agent admin assistant: three agents with handoff between them - support, read-only question answering, and a mutating admin agent - over 40 tools, retrieval across the support documentation, and tracing on every handoff and tool call. Its write operations go through the same commands, and therefore the same permission checks, a human would hit.

The point worth making is not that the system uses AI. It is that both of these landed as ordinary pull requests on an eight-year-old codebase, with no rewrite and no cutover.

Two frontends, two state libraries, on purpose

The admin console and the member portal share an API and a tenancy model but disagree on framework generation and state library, and that is a decision rather than drift. The console optimises for a staff member who keeps a tab open all day: client-rendered, store-owned data, 117 observable stores and permissions applied down to individual form fields.

The member portal optimises for the opposite - first paint on a page that sits next to a studio's marketing site. It supports guest-first browsing, where an anonymous visitor can look at a schedule and prices before an account exists, and an embed mode where the whole app runs in an iframe on the studio's own domain, with an origin whitelist, a height handshake and token passthrough so an already-signed-in member is not asked to log in twice.