How Monody runs at the size of a big operator
A gym of 28 locations and a franchise of 500, run on a copy of the product. Updated 2026-10-23.
Page times at the gym's size
The worst-case time (95th percentile) in milliseconds; a full bar is one second. Measured. A few pages were loaded only once or twice.
A month's renewals, day by day
299,984 members, billed over thirty days with declines, retries and recoveries. Measured.
The two sizes side by side
A gym group
Run 2026-10-2328 locations, 300,000 members, 59 staff.
- Members billed
- 299,984 in 163 s
- Texts sent
- 15,000 in 104 s
- Slowest page
- 873 ms
- Slowest staff query
- 161 ms
A franchise
Run 2026-10-23500 locations in 20 groups, 102,000 members, 500,000 prospects, 10,505 staff.
- Slowest staff query, a location
- 29 ms
- Slowest staff query, head office (500 locations)
- 457 ms
- Sending, jobs and pages
- Not run yet
How we ran it
A copy of the product on a local database, with simulated email, text and payment services. Nothing was charged and nothing was sent. Page times are from a development server that compiles each page on first load, so a production build is faster; they are re-measured on production before this page names them as production.
The data
The gym: 28 locations, 300,000 members, 59 staff. The franchise: 500 locations in 20 groups, 102,000 members, 500,000 prospects, 10,505 staff. Every person, member, plan and payment is invented; the shapes follow what operators of those sizes tell us.
Measured and projected
A measured figure was run on the data above. A projected figure is a measured one scaled to the full month, and the page says so each time. Every figure here carries the date of its run (2026-10-23) and will be re-dated when the run is repeated for a release.
Would it hold at your size?
Tell us your locations and members at a walkthrough and we will say what we have measured near that size, and what we have not.