Martial Arts Studio Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does household billing get scoped as a family identifier column?

Because it is the answer that fits on a slide. Members table, family identifier, sibling discount as a percentage on the child's rate. Everyone in the meeting can picture it and nobody objects, because at that moment nobody is thinking about August.

August is when the Rodriguez family changes. Dad is on adult unlimited under a twelve month agreement, two kids are in the main programme, one is in Little Dragons at the sibling rate, and the whole household sits under a cap. The oldest quits. With a family identifier column, dropping that member removes one line and recalculates nothing. The sibling ladder does not reshuffle. The cap silently over collects or under collects. Dad's agreement term is untouched but the discount that justified it has moved. The desk fixes it by hand, writes the real number on a note, and now the note is the source of truth.

The same defect produces the dunning problem. A declined card generates a message per member, so a family with three enrolments gets three emails about one failed payment, calls the school confused, and someone spends fifteen minutes explaining a system error that is really a data model error.

The fix is to decide the billing unit before anything else is designed. The household owns payment methods, agreements and dunning. Enrolments sit underneath as lines carrying student, programme, schedule, base rate and term, and a rate engine re-evaluates the sibling ladder, household cap, paid in full credits and freeze proration on every change. Make the acceptance test explicit: drop a member mid term and the screen must show the invoice difference before commit, old total against new, line by line, with a reason on each change. If a bidder cannot demonstrate that, they will rebuild the trap you are already in with better fonts.

What goes wrong when you migrate members, agreements and rank history?

Three sources, three different failure modes, and the one that matters most is usually not in any export.

Names, attendance and a belt field come out of Zen Planner, Kicksite or Mindbody cleanly enough. Agreement terms frequently do not, because if you use a third party billing company such as ASF or Member Solutions, the agreements are theirs and the export often omits the terms, the remaining months and the cancellation rights. Family rate arrangements are worse, since in most schools they exist as a spreadsheet or as the desk manager's memory of what was promised.

Rank history is its own problem. A serious school has a filing cabinet of paper rank cards going back years, plus a spreadsheet, plus attendance counts that were never reconciled to promotions. Migrating a belt field alone loses the thing that makes the ladder work: time in grade, curriculum sign off, and which promotions were discretionary.

The failure mode is cutting over on an export nobody reconciled, then discovering in the first billing cycle that forty households are charged an amount that does not match what a parent was told. That conversation is expensive in a business built on trust with families.

The fix is a parallel billing cycle before cutover. Run one full month in the new system without charging anything, compare every household total against the old system line by line, and resolve every difference. Read your billing company contract early, because exit clauses often have teeth and the export you need may require notice. For rank, document extraction reads paper cards into the ladder with a human reviewing exceptions, which compresses a data entry project of many months into a few weeks, but budget the review time rather than assuming it away.

Why do the payment and check-in integrations break after launch?

Money movement is where these builds age badly, and the breakage is rarely dramatic.

Cards expire on a schedule you cannot control, and a school with several hundred households has a steady stream of updates. If the retry ladder is naive, a temporary decline becomes a cancelled enrolment. Bank transfer returns arrive days after the charge appeared to succeed, so a household shows as paid, attends for a week, and then owes money nobody flagged. Refunds and chargebacks need to reverse the right enrolment line rather than the household total, or your revenue reporting drifts quietly for months.

Check-in hardware fails differently. A tablet at the door loses its network on a Tuesday evening with thirty families arriving, and if the application has no offline queue the desk reverts to paper and the attendance record that drives rank eligibility develops a hole. Barcode scanners and receipt printers get replaced by whoever is closest to the problem, with a model nobody tested.

The fix is to treat payments as a subsystem with its own monitoring, not a checkout button. Card updater services, a retry ladder tuned to your own decline patterns, bank transfer returns posted against the household with an automatic hold on entitlements, and a daily reconciliation report between the processor and your ledger that a named person actually reads. For check-in, require an offline queue with local validation and a visible sync indicator, and specify the hardware models in the contract so the replacement in eighteen months is a purchase rather than a project.

What happens when after school custody records and minor waivers are not covered?

If you run pickup, you are running a regulated childcare operation inside a martial arts school, and no platform on the market handles it. The scope conversation usually defers it, because it looks like a rostering feature.

The operational failure is a child on the wrong van with no record of who tapped him off at which school. Everything else about that day is irrelevant once that has happened. The administrative failure is a licensing inspector asking for a timestamped attendance log and the answer being a laminated clipboard and a Google Sheet.

Waivers and photo releases fail more quietly. A minor's waiver signed by one parent, an authorised pickup list that was updated verbally, and allergy or medication information sitting in a profile field nobody opens on the van. Each of those is fine until the day it is not.

The fix is to build the custody chain as a first class record. Rosters generated per school per weekday, a driver manifest on a phone with tap off at the school and tap on at arrival, so there is a timestamped chain from bell to mat. Allergy and medication flags surface on the manifest itself rather than in a profile. Authorised pickup carries a photo checked at release. A live ratio view per room. One button exports the log an inspector asks for. Then treat camp weeks as inventory with capacity, waitlists and swap rules tied to the same household billing engine, so a swap is a schedule change rather than a refund and a re-charge.

Should you build custom or configure what you already own?

One location, under roughly 250 active students, one main programme and no after school: do not build. Zen Planner, Kicksite or Gymdesk at a few hundred dollars a month does most of what you need, and what it misses costs less than the interest on a custom build. We have talked schools out of this exact project and been right to. Spark Membership, PerfectMind and Martialytics are all worth a look at that size, and Mindbody suits schools that also run fitness style class inventory.

There is also a common case where the incumbent tool is not the problem. Many schools use ten percent of what they pay for because nobody was ever trained past check-in, and the reports they rebuild by hand every Sunday exist in the product. Before commissioning anything, book time with your current vendor's support team and ask them specifically how to produce the testing roster and the family billing view you currently build in Sheets. If the honest answer is that it is not possible, you have a fit problem. If the answer is that it takes four clicks, you had a training problem and just saved six figures.

Build when the signals stack. Five hundred or more actives, or three or more locations. A staff member whose real job has become rebuilding reports, since that salary is your build budget in plain sight. A billing company taking a percentage of gross where the annual gap against a normal processor is five figures. After school and camps above roughly a fifth of revenue running on spreadsheets. Or you are franchising, at which point your operating system is part of what you sell and you cannot license somebody else's.

How do hidden costs get into the quote?

Six items account for most of the overrun in this category, and money movement leads every time.

• Payments engineering. Bank transfer returns, retry ladders, proration on mid cycle changes, refunds, chargebacks and keeping card data scope small through tokenization. Quoted as an integration, delivered as a subsystem.
• Exiting a third party billing company. Contract notice, an export that omits agreement terms, and the reconstruction of those terms household by household.
• Migration debt. A decade of platform history, paper rank cards and a private spreadsheet of family rates that has to be turned into rules.
• After school and camps. Licensing reporting and custody records are not optional once you run pickup, and they are a separate product hiding inside the project.
• Hardware. Kiosks, scanners, receipt printers and tablets that live beside a mat, plus the network they depend on.
• Programme count. Each programme with a genuinely different rank ladder is a rule set somebody has to sit down and describe correctly, and describing it is your time, not the developer's.

What keeps cost down is a first release limited to household billing, check-in, rank eligibility and a staff application, with the parent application, pro shop and after school phased later.

What separates a build that works from one that fails here?

The rank ladder is configuration, not code. Adding a new programme with different requirements should be an afternoon for your head instructor, not a change order. If adding a discipline to your schedule needs a developer, you have bought a custom prison rather than a custom platform.

Instructors sign off on a tablet at the edge of the mat in two taps, standing up, with a gloved or taped hand. Anything that requires sitting down at the desk will be done from memory on Sunday, and rank eligibility built on remembered attendance is worse than no system at all.

The eligibility job produces three lists rather than a dashboard: the testing roster with the reason each student qualified, the students who are two classes short so the desk can call before the cycle closes, and the blocked list with balance or sign off issues while there is still time to fix them.

Churn surfaces as a queue with names and reasons on a Monday morning, measured against each student's own baseline rather than a fixed thirty day threshold. Thirty days with no attendance is a record of a decision already made.

And ownership is settled before kickoff. The repository lives in your organisation from the first commit, infrastructure and the merchant account are in your name, and there is a runbook another team could pick up. At Digital Heroes that is the default, and a developer who hesitates at that sentence has told you what the relationship will be like in year two.