CrossFit Box Software: Fixing the Booking, Billing and Payroll Leaks

Why booking and membership software makes or breaks a CrossFit box operator

Every box owner has the same Sunday night. The head coach is in a Google Doc writing next week's programming, copying the metcon into Wodify by hand because the Doc is where the cycle actually lives. The front desk person is in Stripe hunting a failed card for a member who has been checking into 5:30am for nine days without paying. A coach texts to say she covered two classes last week that never made it into the schedule, so payroll is wrong again. And somewhere in a Google Sheet is the real membership count, because the number in the software counts three people who quit in March and still have an active hold.

The tool stack is predictable: Wodify or PushPress or Zen Planner for memberships and class booking, SugarWOD or a Google Doc for programming, Stripe or a payment processor bolted on, Gymdesk or Mindbody if the box grew out of a boutique studio, plus WhatsApp groups, a Squarespace site, and a Sheet that reconciles all of it. Wodify's published tiers run roughly $130 to $500 a month per location depending on member count. Mindbody starts near $159 a month and climbs hard with add-ons. None of that is the real cost. The real cost is the 8 to 12 hours a week your general manager spends being the integration layer: exporting attendance, matching it against billing, chasing holds, rebuilding the coach pay sheet, and answering "why did it charge me twice" in DMs.

The scene that ends the debate: a three-location box we worked with ran a hybrid membership, unlimited at the home box plus two drop-ins a month at the other two. Their platform could not model it. So they created three separate memberships, told the member to book manually, and tracked the cross-box visits in a Sheet. By the time anyone counted, the unbilled drop-ins and misapplied credits had been accumulating for the better part of two years, and nobody had noticed, because the software's revenue report was, technically, correct about itself.

Problem 1: your membership model is more complicated than the software believes

Boxes do not sell one thing. You sell unlimited, 3x a week, open gym only, a nutrition add-on, a barbell club that meets Tuesday and Thursday, a personal training block of 12 sessions that expires in 90 days, kids classes billed to a parent's card, a military discount, a founding member rate you promised in 2019 and cannot legally change, and a family plan where the third person is free. Off-the-shelf tools model membership as a plan with a price and a class cap. Everything else becomes a discount code, a manual credit, or a note in a field nobody reads.

Wodify and PushPress cannot fix this because their data model is plan-centric, not entitlement-centric. A plan has attributes. An entitlement is a rule: this person, at this location, for this class type, in this window, has this many uses, decremented in this order, with this priority against their other entitlements. When a member with unlimited plus a PT block books a PT session, which bucket pays? The off-the-shelf answer is "whichever the front desk clicks." That is not a bug you can support-ticket away, it is the shape of their schema.

A custom build separates member, agreement, and entitlement into three tables. An agreement generates entitlements on a schedule. Bookings consume entitlements through a resolver with explicit priority: expiring-soonest first, then most restrictive, then unlimited as fallback. Cross-location visits carry a location tag and a settlement rule so the revenue lands at the box that delivered the class, which matters the day you open location four with a different partner split. Every consumption writes an immutable ledger row. When a member asks why they were charged, you show them the row, not a guess.

Problem 2: programming lives in a Google Doc because the software makes it painful

Your head coach writes in cycles: a nine week strength progression with percentages off a tested 1RM, conditioning that varies by track (competitor, general, masters), and scaling options for three levels. SugarWOD stores a workout as text. Wodify stores components with a bit of structure. Neither models a cycle as a program with a progression rule tied to each athlete's tested maxes, which is why your coach writes "75% of 1RM" in a Doc and every athlete does the math wrong at 6am on a whiteboard.

The off-the-shelf failure here is that programming is treated as content, not computation. The tool cannot answer: which athletes are due to retest their back squat, who has missed more than 40% of the strength days in this cycle so their percentages are stale, and what did the competitor track actually do in weeks 4 through 6 last season. Your coach can answer those, from memory, which works right up until you hire a second head coach at location two and the answers diverge.

A custom build stores programming as a template with parameterized loads. The athlete's screen resolves percentages against their own tested maxes at display time, so the whiteboard shows 235 pounds, not 75%. Track assignment is a member attribute, so one publish action fans out three versions. Retest reminders fire off attendance data. AI does one useful thing here: your head coach dictates or pastes the cycle from wherever they wrote it, and an extraction model parses it into structured movements, sets, reps, and load rules, with a review screen before publish. That kills the retyping without asking your coach to change how they think. The model does the parsing, the coach does the approving.

Problem 3: coach payroll is a spreadsheet crime scene

Coaches get paid per class, sometimes with a head-count bonus above 12 athletes, sometimes hourly for open gym, sometimes on a rev share for PT, sometimes a flat rate if they are also your GM. A cover means the pay follows the person who actually coached, not the person on the published schedule. Nobody's software knows this happened unless someone types it in.

Wodify and Zen Planner do not fix it because their schedule is a publishing artifact, not an attendance-of-staff record. There is no reliable "who actually stood in front of this class" event, so payroll is reconstructed from memory, in a Sheet, on the 1st, by someone who was not there. At 9 coaches and 190 classes a week, the errors you cannot see are real money and, worse, they are the thing coaches quit over.

A custom build makes coach check-in a first-class event, tapped on the same tablet the members use. The class record stores scheduled coach and actual coach separately. Pay rules are configuration, not code: per-class rate, headcount tiers, PT split percentage, all versioned so a raise in April does not rewrite March. The payroll run reads the ledger and produces a per-coach statement with every class listed, which the coach can see all month instead of disputing after the fact. Export to Gusto or your provider is a file, not a retype.

Problem 4: attrition is visible in your data three weeks before the cancel email

The member who cancels in week 12 stopped coming to 6am in week 8, dropped from 4 visits a week to 1, quietly stopped logging scores, and never replied to the auto email your tool sent on day 21. By the time your retention report shows them, they have already told their spouse they are quitting. Your GM knows this pattern in their gut and covers maybe the 30 members they personally know. At 700 members that is not coverage, that is luck.

The off-the-shelf tools ship "engagement reports" that are attendance counts on a chart. They cannot fix this because the signal is not attendance level, it is attendance shape: which class time they anchored to, whether their training partner left, whether their PR curve flattened, whether they went from booking 6 days ahead to same-day. Those features live across booking, programming, and payment tables that the vendor keeps separated by design.

A custom build computes a per-member risk score nightly from behavior your box actually generates: rolling 4-week visit delta against their own baseline, loss of their most-frequent class slot, days since last logged score, failed payment in the last 60 days, and whether their two most-common training partners still attend. The model that pays here is dull: trained on your own churn history, not an industry benchmark, it surfaces a ranked list of 15 names each Monday with the reason attached. Your GM makes 15 calls, not 700. The same model drafts the outreach in the coach's voice, and a human sends it. In the boxes above 400 members we have built this for, it moves save rate, but only because the intervention is a human calling, not another automated email.

Problem 5: after-hours leads and drop-ins die in a DM

Someone visiting from out of town DMs your Instagram at 9:40pm asking if they can drop in at 6am. Your front desk sees it at 8:15am. They booked at the box down the street. A local lead fills out your Squarespace form at 10pm asking about the intro package, and your automated email answers a question they did not ask. Drop-ins at $25 to $35 and intro packages at $99 to $299 are not rounding errors at volume.

Off-the-shelf booking widgets fail here because they require the visitor to understand your class structure, waiver, and membership vocabulary before they can transact. A drop-in visitor does not know whether "CrossFit" or "Metcon 60" is the thing they want, and they will not create an account to find out.

A custom build puts a conversational booking agent on Instagram DM, SMS, and your site that reads live class capacity, answers in plain language, collects the waiver signature, takes the $30 by card, and puts the person on the 6am roster before your GM wakes up. It escalates to a human on anything about injuries, refunds, or membership changes. That guardrail is the whole design: the AI handles the transaction it can complete, and hands off the conversation that needs judgment. The same agent handles the "can I switch from 5:30 to 6:30 this week" traffic that eats your front desk's morning.

What this costs and how long it takes

Across 2,000-plus projects, Digital Heroes sees this category land in two bands. A focused first release, meaning the entitlement engine, class booking, member check-in, Stripe billing with holds and proration, and coach check-in with payroll export, runs $60k to $130k and ships in 12 to 16 weeks. A full platform, adding programming with per-athlete load resolution, a branded member app on iOS and Android, retail and inventory, multi-location settlement, the retention model, and the booking agent, runs $150k to $400k phased over 6 to 12 months.

Where the money actually goes. First, the member mobile app: a real one with offline whiteboard, push, and Apple and Google review cycles adds $40k to $80k and about 6 weeks of calendar you cannot compress. Second, billing edge cases: holds, prorations, family plans, annual prepay, and failed-card dunning are where the requirements triple, and they are not optional because they are 100% of your revenue. Third, migration from Wodify or Mindbody: their export gives you members and plans but not the history you actually need, so budget $10k to $25k for reconciliation and a parallel-run month. Fourth, PCI scope: tokenize with Stripe and stay out of it, or store card data yourself and add six figures of compliance you do not want. Fifth, every additional location with a different revenue split or franchise agreement adds real modeling work, not a config toggle.

Build versus buy, and the exact line

Buy. If you are one or two locations under 500 members with a normal membership menu, PushPress at $159 to $259 a month or Wodify is genuinely the right answer and I will not pretend otherwise. Your bottleneck is coaching quality and lead flow, not software. Building your own booking engine at that size is a hobby that costs you the thing that actually grows the box.

Build. The signals are specific, and they are about labor and lock-in, not annoyance. One: you have three or more locations and your revenue reporting requires a human to combine exports. Two: your GM spends more than 8 hours a week reconciling systems, which at a $70k GM is roughly $14k a year of pure integration labor. Three: you have a membership or pricing model you want to sell and cannot, so you are faking it with discount codes. Four: you are franchising or licensing, and your operating model is the product, which means the software has to encode it. Five: your combined SaaS bill across locations plus add-ons crosses $2,000 a month.

Here is the position. Above roughly 800 active members or three locations, the off-the-shelf tools stop being software and start being a tax: you pay per member for a product that makes your best operator do data entry. Below that line, building is vanity. The line is not about how frustrated you are, it is about whether the reconciliation labor plus the deals you cannot do exceed the build. Do that math before anything else.

How to choose a developer for gym and box management software

Put your membership menu in front of them on the first call and ask for the data model, not wireframes. If they draw members, plans, and bookings and stop, they have not built this. The right answer separates agreement from entitlement from consumption and immediately asks you about holds, family plans, and what happens when a PT block expires with 3 sessions left. That question is the tell.

Ask what they will do with your Wodify or Mindbody export. Correct answer: a mapping document and a parallel-run month where both systems bill and you diff the output before cutover. Wrong answer: a one-time import script and a go-live date. Members notice billing errors within one cycle, and you get one chance.

Ask specifically about Stripe or your processor, not "payments." They should talk about tokenization so card data never touches your database, SCA and 3DS handling if you have any international members, dunning and retry logic on failed cards, and how a mid-cycle plan change prorates. If they say they will "handle billing," they mean they will build a bug.

Ask who owns the code, in writing, before the deposit. You should get the repository, the infrastructure account, and the deployment pipeline in your name from day one, not on final payment. Also ask what happens at month 14 when you want a change: get the support model and rate written down. A gym platform is an operating dependency, and a developer who cannot commit to being reachable is a developer who is renting you a liability.