A dance studio with 200 students runs on three systems that don't talk to each other: a scheduling app, a payment processor, and a spreadsheet someone has been maintaining since 2018. Every recital season, the owner exports from one, imports to another, and manually reconciles everything that broke in transit. The studio is thriving. The dance studio software category built to serve it is not.
The problem isn't that no one has built scheduling and billing tools for dance studios. Those exist. The problem is that scheduling and billing are not the real job. The real job is managing enrollment momentum, running a recital without losing staff or parents, and building communication flows that actually change parent behavior. Nobody has built that product because nobody who built the current ones ran a studio for ten years.
The enrollment lifecycle nobody modeled correctly
Most vertical SaaS products in the fitness and activity space organized themselves around two functions: class scheduling and payment collection. Both matter. Neither is the lever that determines whether a studio grows past 150 students or plateaus there.
The enrollment lifecycle — the sequence of decisions a parent makes from first inquiry call through annual re-registration — is highly specific to studio culture, pricing structure, and recital timing. A new student family in October is making a different decision than one in January. A student in competitive company is on a different retention track than one in recreational classes. Generic booking flows don't model any of this.
The studios that grow past 300 students build custom workarounds for enrollment management. Zapier automations, staff-maintained spreadsheets, elaborate Notion databases. The operator who built those workarounds already knows exactly what the software should do. They just haven't had a reason to build it yet.
Recital logistics as an untouched product surface
Recital planning is a seasonal intensive that pulls studio staff away from everything else for six to eight weeks every spring. Costume ordering, tights sizing, photo day scheduling, stage logistics, and ticket sales each have dependencies the others don't account for. Costume delivery needs to happen before photo day. Ticket sales affect stage configuration. Photo day scheduling depends on which classes share a recital time slot.
No dedicated product has been built for recital logistics because the people who built dance studio software never ran a recital. The use case is predictable, annual, and high-stakes for the studio owner. It's also invisible to a product team that interviewed studio owners once and never observed a recital week from the inside.
Where parent communication actually breaks down
Dance studio owners aren't looking for more parent communication features. Every current platform has a parent portal, automated reminders, and missed-class notifications. What's broken is the triggering logic — when messages go out, to which parents, and whether the message contains anything actionable.
A reminder that goes to all parents three days before class is noise. A reminder that goes to the parents of students who have missed two consecutive weeks, worded specifically to address that, and timed to reach them on a Tuesday evening when they're planning the week — that changes behavior. The difference isn't a new feature. It's a different set of product decisions that only gets made when the builder has watched parent communication work and fail in the wild.
The operator founder who ran a studio with five teachers across three locations has seen which messages parents actually read and which they filter out. That product intuition doesn't come from a design sprint.
What the next dance studio software product needs
The gap in this category isn't features — it's vertical depth. A product built by someone who ran a studio for a decade would make different decisions at every layer: data model, notification logic, recital tooling, staff scheduling relative to class demand, registration flow sequencing. The product doesn't need to be larger than what exists. It needs to be more accurate.
The distribution question is also different for an operator-founder here. Dance studio owners talk to each other at the same conventions, in the same Facebook groups, and through the same regional studio owner networks. A founder who builds the right product and gets it in front of 20 studios will see the next 200 come through referrals before a marketing budget is ever needed.
If you've run a dance studio and spent years working around software that doesn't fit the job, that's the context we look for in a co-founder. We build alongside operators who already understand the problem.