The gym stopped renting its own member list

A member asked us to stop emailing her every time she booked a class. That was the whole request. One preference, one checkbox, a thing any reasonable person would assume already existed.

Under the old arrangement the honest answer was: I will raise it with the vendor. And the honest translation of that sentence, after a few years of saying it, is: that will never exist.

That is the problem I want to describe, and the invoice is the least interesting part of it.

What the gym was actually paying for

Persistence Athletics is a gym in Seattle. I own it, my wife coaches there, and until this May it ran on Wodify, which is the default management platform in the CrossFit world. Wodify held the member list. It held the class schedule, the memberships, the signed waivers, and every member's training history going back years: every class attended, every lift logged, every personal record.

The gym owned none of that. It rented all of it, and the rent was $3,600 a year.

The gym stopped paying that rent in May, and that part I will state flatly rather than hedge: it is my own gym, I cancelled the subscription myself, and there is no vendor invoice after the cutover. The $3,600 a year comes from my own records rather than a re-pulled invoice, so treat the exact figure as the operator's number. The fact that it stopped is not in question.

But the subscription was never the real cost, and I think this is the part small business owners consistently underprice. The real cost was the set of things that could not exist. A coach members could message at 9pm. A rewards program that pays people for showing up. Member profiles that make the app feel like the community rather than a booking form. An email preference. Each of those was either a support ticket that went nowhere, or a roadmap conversation with a company whose roadmap correctly serves thousands of gyms and therefore serves no gym in particular.

The gym was paying rent on its own information, and the terms of the lease were that it could not change anything.

old: the member list, the schedule and years of history live in a vendor's database
new: the same data lives in a database the gym owns, and a member request ships the same day

What I built, in plain terms

I replaced the whole system. Not the interesting parts of it, the whole thing, because a half migration means running two sources of truth and that is worse than either one alone.

The new system runs class booking and the schedule, billing and invoicing with taxes and account credits, waivers, an attendance rewards program where every class earns credit toward membership, member profiles with photos and birthdays and PR shoutouts, set by set lift logging with weight suggestions based on each member's own maxes, an AI coach members can text at 9pm, and a space rentals product that lets an outside group get a quote, sign, and pay without anyone at the gym touching it. It is a web app with native iOS and Android apps over the top, and it went into the App Store and the Play Store in early May.

Two decisions actually mattered. Everything else was work.

The history had to come across, or nobody would move. This is the thing that keeps gyms locked in, and it has nothing to do with features. A member who has been training for six years does not care about your billing architecture. She cares that the app still knows she squatted 225 in March. If the new system starts everyone at zero, you have not migrated your members, you have asked them to abandon their own record and start again, and a meaningful number of them will decide that is a good moment to try the gym down the street instead. So the migration moved members, memberships and waivers, and it moved years of attendance history and personal records with them. Nobody lost their story. That was the requirement everything else was built around.

The cutover was one weekend, not a phased rollout. May 2 to May 3, 2026. Everyone moved at once. Running both systems in parallel sounds safer and is not, because the moment two systems can both accept a booking you have a reconciliation problem forever, and every bug becomes an argument about which database is right. A single weekend is scarier on the day and much cheaper afterward. First live billing ran the following Sunday.

The reason a single weekend was possible at all is that I built the system with Claude Code as the actual implementer rather than as an autocomplete tool. That is the only place in this story where the technology explains the outcome. The migration scripts, the reconciliation checks, the edge cases in years of messy attendance data: that is weeks of careful work at normal speed, and normal speed would have meant a phased rollout, and a phased rollout would have meant two sources of truth. Cheap implementation did not make the software better. It made a cleaner plan affordable.

What changed, and what the numbers mean

Three months of running on it, May 1 through July 31. These come from the platform's own database.

Class visits. 1,471 check-ins across the quarter: 458 in May, 492 in June, 521 in July, across 482 classes held. July was 14% above May. Re-pulled on 16 August, the same window reads 1,483, because check-ins kept getting recorded after the original query ran. I am leaving the published numbers where they are and noting the drift rather than quietly restating them.

Training logged. 1,134 lifts logged and 905 personal records detected and celebrated automatically since launch.

Members and money. As of the end of July, 63 active members and 8 people on free trials. As of August 3, 61 active memberships carrying $16,705 of monthly recurring revenue, a weighted average of $274 per member per month. For comparison, a snapshot on June 4 showed $13,016 across 41 paying members.

One correction to that last paragraph, because I got it wrong the first time. The $16,705 prices every active membership at list, including the complimentary ones, so it is a contract-value number and not cash. Re-pulled on 16 August, the same database reads 54 active memberships, of which 38 are paying and 16 are complimentary, and the paying ones carry $12.3K of monthly recurring revenue. Collections tell the more honest story: $12.2K in May, $12.4K in June, $13.4K in July.

Speed. The member who wanted the email opt-out asked on a Monday. It was live that Monday.

Now the limits, because these numbers are softer than they look.

The monthly recurring figure is theoretical. Actual collections in July were $13.4K against that $16.7K, and the gap is real: discounts, partial months, accounts that are not billing. If I quoted you the $16,705 and not the $13.4K I would be selling you a number the bank account does not agree with.

The growth line is not clean either. June 4 read $13,016, a different snapshot on June 25 read roughly $11.4K, and August 3 read $16,705. Those were pulled by different scripts on different days against a live database, not closed books. The direction over the quarter is up and I believe it. The month to month shape is noise I would not defend.

The 14% attendance growth is three months in one Seattle summer at one gym, and membership grew over the same period, so it is not a clean measure of members training more often. It is more visits happening. That is worth having and it is not the same claim.

The 905 personal records are records the app detected, and the app can only detect what members log. Under the old system a lot of that was never logged at all, so this is not a like for like improvement over Wodify. It is a measure of how much the gym can now see.

And the operating cost. The software line item dropped by roughly an order of magnitude, from $3,600 a year to hosting plus API usage. That is true and I would rather you noticed that it is also the least important number here. If the only thing this project had done was cut a few thousand dollars a year of software cost, it would not have been worth building.

The thing I would actually point at is space rentals: a revenue line that did not exist under the old vendor, where an outside group can quote, sign and pay end to end without a person in the loop. I am not going to give you a dollar figure for it, because I do not have one I have personally traced to a bank statement, and this is exactly the kind of number a case study would round up. The product exists and it works. That is the claim.

One more, from June, when I was measuring the funnel rather than the software: trial conversion at 60 days was 29.6%, which is 8 of 27. Small numbers, and I have not recomputed it since.

What this looks like in other businesses

The gym is not the point. The pattern is.

If your business depends on a vendor that holds your customer list, your schedule, and your customers' history, then the subscription is not what you are paying. You are paying for a permanent ceiling on what your business is allowed to be. Every idea you have gets filtered through whether a company in another state, serving thousands of customers who are not you, finds it worth building. Most of your good ideas will not survive that filter, and you will stop having them, which is the expensive part and the part that never appears on a P&L.

The test I would apply is not a cost comparison. It is this: think of the three changes you would most like to make to how customers experience your business. Now ask how many of them require permission from a vendor. If the answer is three, the software is running the business rather than the other way around.

The counterargument is real and I will make it for you: vendors handle payments compliance, security, uptime and support, and a small business that rebuilds all of that badly has bought itself a disaster rather than a platform. That is correct. The reason this was a good trade for the gym is not that the vendor was bad. It is that the gym had specific, unbuyable ideas about its own members, and now it can act on them the same afternoon it has them.

If you are running a business on software that fits most of your workflow and blocks the parts you care about most, that is the work Autosterea does.