Dance Studio Software: Fixing Recitals, Family Billing and Class Placement

Why dance studio software makes or breaks a multi-location studio owner

A dance studio looks like a gym with tights until you open the billing. A gym sells one thing to one person. You sell a Tuesday 4:15 Ballet II to a nine year old, bill her mother, who also has a seven year old in Tap I and a fourteen year old on competition team, on a family account with a sibling discount, an autopay card that expired in February, a costume deposit that was due in November, and a recital ticket allocation that depends on how many routines her three kids are in. That is one family. You have 900.

The tools you are running now were built for the first problem, not the third. Jackrabbit Class handles enrollment and family billing genuinely well and prices around $59 to $199 a month by student count. DanceStudio-Pro is cheaper and dance-native, with costume and recital modules bolted on. Mindbody, if you inherited it from a fitness-minded predecessor, does not understand families at all, it understands individuals with memberships, which is why your front desk has a shared Google Sheet called FAMILY MERGES. Studio Director, Akada, Class Manager, iClassPro: same shape, same ceiling.

Here is the scene that tells you where you actually are. It is early May. Your studio director has a laptop open with four tabs: Jackrabbit for enrollment counts, a Google Sheet named RECITAL_2026_FINAL_v7 with a tab per routine, a Dropbox folder of costume size charts as PDFs from three vendors, and Gmail, where 40 parents are asking why they were charged $85 for a costume their daughter is not wearing because she dropped Jazz II in March. The routine order was rebuilt by hand for the third time because a quick-change conflict was found: one dancer is in routine 12 and routine 14 with a costume that takes four minutes to get into. That fix took two hours and broke two other things. Across a recital season we routinely see 120 to 200 hours of this per location, and that is before ticketing. At a studio director's loaded cost, that is real money, and it is the same money every single year.

Problem 1: the family account is the real unit, and your software thinks it is the student

Mrs. Alvarez has three dancers in eleven classes. Your sibling discount is 10% off the second dancer, 15% off the third, but not on competition team tuition, and not on the summer intensive. Two of the kids are on her card, the third is billed to her ex-husband under a court arrangement. In Jackrabbit you can approximate this. In Mindbody you cannot, so someone created two accounts and now the sibling discount is applied by hand every month via an account credit that a part-time admin has to remember.

Off-the-shelf tools cannot fix this because the discount engine is a flat rule table, not a policy engine. They give you a percentage field and a checkbox. They do not give you: discount tier by dancer rank within household, exclusion by class category, split-payer allocation on a single invoice, and proration rules that differ between drop mid-month and withdraw before the 15th.

What a custom build does: model the household as a first-class object with dancers, payers, payment methods, and payer allocation rules attached to it, and put your tuition policy in a rules engine your director can edit without a developer. Every invoice line carries its provenance: base tuition, which discount rule fired, which payer it was allocated to, what proration applied and why. When Mrs. Alvarez calls, your front desk clicks the line and reads her the reason instead of saying they will look into it. We build a dry-run mode so the director can run next month's billing against current enrollment and see the totals and every changed line before a single card is charged. That one screen kills the majority of billing disputes because it catches the bad rule before the parent does.

Problem 2: recital production is the highest-stakes workflow and it lives in a spreadsheet

The routine order is a constraint-satisfaction problem and everyone solves it by hand. The constraints are real and you know all of them: a dancer needs at least two routines of gap between costume changes, more if the change is a full unitard, the youngest ages should not be scheduled last, teachers who are also performing cannot be backstage wrangling, Act I and Act II need balanced runtime, and the finale needs everyone. Add a second show for capacity and the whole thing doubles.

DanceStudio-Pro has a recital module. It gives you a list you can drag around. It does not know that Emma is in routines 12 and 14, or that routine 12's costume is a two-piece with a headpiece that takes four minutes. It cannot tell you that before the show, only your stage manager can, in dress rehearsal, at 9pm, badly.

What a custom build does: it holds the dancer-to-routine graph and the costume-change-time attribute per routine, and runs the ordering as a solver. You set constraints, minimum gap by change complexity, act balance, age curve, teacher availability, and it produces a valid order in seconds plus a ranked list of what it had to relax. Change a cast at 4pm on Thursday and it re-solves and shows you the diff: three routines moved, one new conflict, here it is. This is the AI spend that returns money in this category, not a chatbot, an optimizer over your actual constraints. Alongside it, every downstream artifact generates from the same graph: backstage call sheets per dancer, quick-change lists per wing, the program in printable order, the video chapter markers. Nobody retypes anything.

Problem 3: costumes leak thousands per season and nobody can see where

Costume ordering is a purchase commitment made in November against an enrollment that will not hold. You order 42 of a style, 6 dancers drop by February, 3 join in January in sizes you did not order, 2 need alterations, one vendor backorders and ships in April. Meanwhile the parent portal shows a $85 costume fee charged to every enrolled dancer as of the November snapshot, and the reconciliation between what you charged, what you ordered, what arrived, and what got worn happens in a spreadsheet, once, angrily, in June.

Incumbent tools charge the fee. They do not run a costume as an inventory item with a lifecycle. There is no purchase order object, no vendor SKU, no size chart, no receiving step, no per-dancer assignment, so there is nothing to reconcile against. Across the studios we have worked with, the unreconciled gap between costume fees collected and costume cost actually incurred lands in the low five figures a season per location, and it goes both directions: sometimes you ate the cost, sometimes you overcharged a parent and they told forty other parents.

What a custom build does: costume becomes an object with vendor, SKU, size run, unit cost, lead time, and a state machine from ordered to received to assigned to worn. It is linked to the routine, and the routine is linked to the roster, so the moment a dancer drops the system tells you: this costume is now unassigned, it is a size 8, these two January enrollees need a size 8, reassign or return by the vendor's cutoff of March 3. The parent charge is driven off assignment, not off a November snapshot, so a drop triggers the correct credit automatically. On the vendor side, document extraction handles the packing slips and invoices: your admin photographs or forwards the PDF, the system reads line items and quantities and matches them to the purchase order, flagging the shorts. That is a task that eats a full day per shipment done by hand and takes about ten minutes with a human confirming the flags.

Problem 4: enrollment happens at 9pm and your front desk is asleep

Registration week is the single highest-value week of your year, and the parent doing it is a working mother on her phone at 9:15pm who has a specific question: my daughter is eight, she did two years of rec ballet somewhere else, which class does she go in, and does it conflict with her brother's Tuesday tap? Your website has a class grid. The grid does not answer her question. So she emails, and gets an answer 14 hours later, and by then she has enrolled at the studio across town.

Jackrabbit and iClassPro give you a registration form. They do not give you placement logic, because placement is your artistic director's judgment: age plus prior training plus a level chart plus whether the Tuesday 5:30 already has 18 in it. And they cannot answer a question in natural language at 9:15pm.

What a custom build does: encode the placement chart as data (age bands, prerequisite levels, teacher-override flags, cap per class) and put an AI intake agent in front of it that is grounded strictly in your class catalog, your placement rules, and the family's existing schedule. It asks the two questions it needs, proposes a specific class with a specific time, checks the sibling conflict, and either enrolls or, when the answer is genuinely a judgment call, writes a structured placement request to your artistic director's queue with everything already gathered. The rule we hold to: the agent never invents a placement, it either matches a rule or escalates with a complete file. The same engine handles waitlist promotion, so when a spot opens in the Tuesday 5:30 the next family gets an offer with a 24 hour hold instead of waiting for someone to notice.

Problem 5: multi-location makes every report a lie

Three locations, three Jackrabbit instances or one instance with location tags that half your staff ignore. A family with one dancer at the north studio and one downtown is two families. Your teacher who covers both is two staff records with two availability calendars that can and do double-book her. Your monthly number is a manual roll-up in a spreadsheet, so you learn that the downtown location's retention fell off in October sometime in December.

This is where off-the-shelf stops being a discount and starts being a tax. The tools were built single-tenant-per-studio, and multi-location is a tag, not an architecture. Cross-location household identity, one teacher with one calendar across sites, and a real-time roll-up of enrollment, revenue per available class slot, and retention by cohort are simply not in the product.

What a custom build does: one household record across all locations, one staff record with one availability calendar that hard-blocks conflicts including travel time between sites, and a metrics layer built on the transactional data rather than exported from it. The number that matters in this business is retention by cohort by class by teacher, because you can act on it: your Wednesday 4:15 Ballet I under one teacher retains at a visibly different rate than the same class under another, and you can only see that if the data model knows what a cohort is. Forecasting on top of it is worth building once you have two seasons of history: given current enrollment and last year's attrition curve by level, here is your April headcount by routine, which is the number your costume order actually depends on.

What this costs and how long it takes

These are Digital Heroes bands from delivery across 2,000+ projects, not market averages. A focused first release, the piece that is actually bleeding, typically runs $60k to $130k and ships in 12 to 16 weeks. For most studios that first release is either the family billing and enrollment core or the recital and costume production system, never both. A full platform covering enrollment, placement, family billing, recital production, costume inventory, staff scheduling, parent portal and reporting runs $150k to $400k phased over 6 to 12 months, shipped in slices you use as they land rather than one launch day.

What drives price up specifically in this category: payments, first and worst. Card-on-file autopay across 900 families with split payers, retries on decline, and ACH means a real payment integration with Stripe or a similar processor plus a dispute and dunning flow, and if you take payment info anywhere near your own servers you are in PCI scope and the cost jumps. Keep card data in the processor's vault and out of your database. Second: the recital solver, because constraints are cheap to describe and expensive to satisfy well, budget a discrete chunk for it. Third: migration. Ten years of Jackrabbit history with duplicate families, dancers who appear three times, and costume fees recorded as generic line items is a real project on its own, typically 3 to 5 weeks, and the studios that skip it regret it in month two. Fourth: minors. You are holding names, dates of birth, photos and video of children, which puts you in COPPA territory in the US and means media consent has to be a per-dancer field enforced at the point where photos and video get used, not a PDF in a filing cabinet.

Build versus buy: take the honest side

Buy. Genuinely, buy, if you are one or two locations under roughly 300 families with a recital under 30 routines. Jackrabbit at $200 a month is not your constraint, and $80k spent on software instead of a second studio director or a third studio is a bad trade. Most studios that call us at this size do not have a software problem, they have a two-people problem. We say so.

Build when these are true together, and they usually arrive together: three or more locations, 800+ enrolled dancers, a recital of 50+ routines across two shows, and at least one full-time person whose week is mostly reconciling systems that should agree. The concrete signals: your recital order is built in a spreadsheet outside the software, you cannot answer retention by teacher without a manual export, your costume reconciliation gap is five figures, and you have paid for a second tool to cover the first tool's gap and are now maintaining the seam between them. When a studio owner can name the 30+ monthly hours and the annual leak, the arithmetic decides it, not taste. The position we hold: build the workflow that is unique to you, the recital and costume and placement machinery, and keep buying commodity where you can, payments, email, accounting. Do not rebuild Stripe. Do rebuild the spreadsheet, because the spreadsheet is your operation.

How to choose a developer for dance studio software

First, make them model the household in front of you before you sign anything. Ask them to sketch the data model for a family with three dancers, two payers, a sibling discount that excludes competition tuition, and a mid-month drop. If they draw a Student table with a parent_email column, they are going to build you a fourth Mindbody. The household, the payer allocation, and the enrollment-as-a-dated-fact are the three objects that decide whether this works.

Second, ask what they have shipped that involves recurring billing against a changing roster. Not e-commerce. Recurring billing where the thing being billed for changes mid-cycle, with proration and credits and a dispute trail. That is the hard part, and a team that has done it will immediately start talking about idempotency, retries, and dry runs. A team that has not will say Stripe handles that.

Third, get their migration plan in writing before the build starts, with the dedupe strategy named. Ask specifically how they will handle families that exist twice in Jackrabbit and how you will verify the money moved correctly. The right answer includes a reconciliation report you sign off on and a period where both systems run.

Fourth, ask directly who owns the code and where it lives. You should own the repository, the infrastructure accounts, and the data, from day one, in your name, not the agency's. Ask them to say it plainly. Then ask how they handle minors' data and media consent, and see whether they already know that consent has to live on the dancer record and gate the media pipeline, or whether they think it is a checkbox on the registration form.