RecitalDash is dance studio management software. It handles class enrollment, student records, billing, and recital production — the operational backbone of a working dance studio. It’s also one of the more complex products we’ve built, because dance studios turn out to have operational problems that don’t map cleanly to off-the-shelf tools.
Here’s the full story.
The Problem
We didn’t go looking for this one. A studio owner reached out through a mutual contact — she’d heard we built software and wanted to talk. The conversation lasted ninety minutes.
The workflow she described went something like this: enrollment was managed in a spreadsheet. Billing was done through a combination of PayPal invoices and a separate Stripe account she’d set up herself. Recital planning — costume sizing, performance schedules, casting — lived in a mix of Google Sheets and paper forms she’d distribute to parents. Communication was through a Facebook group and individual emails. She had 280 students.
The tool she was using before we talked, a competitor with a long presence in the market, had broken billing integrations and a UI that hadn’t been meaningfully updated in years. The two other studios she’d asked about their software were using the same tool and had the same complaints.
We asked the obvious question: how much time per week goes to this operational overhead? Her answer: ten to twelve hours, split between her and one part-time admin. For a studio her size, that was unsustainable — and it was getting worse as the studio grew.
Validation
Before building anything, we called eight more dance studio owners — referrals from the first, and cold outreach through a dance teacher Facebook group. We asked the same questions: what software are you using, what do you hate about it, what do you do manually that you wish was automated.
The pattern was consistent enough to act on:
- Every studio over about 100 students was using some combination of purpose-built studio software and workarounds (spreadsheets, separate payment tools, paper forms)
- The recital planning workflow was almost universally manual, even at studios using modern management software
- Billing — specifically the ability to charge different rates for different class types, handle sibling discounts, and manage costume fees alongside tuition — was a consistent pain point
The market for dance studio management software exists. Several products already serve it. But the recital production workflow was genuinely underserved — it’s complex enough that most tools had either simplified it into uselessness or skipped it entirely.
That became our angle: a tool that handles the full operation of a dance studio, with recital production as the differentiating feature.
Scoping the MVP
The temptation with a “studio management platform” is to try to build everything. We cut it hard.
MVP scope:
- Student enrollment and class management (one studio, one location)
- Billing: recurring monthly tuition with basic rate variations
- A recital module: show creation, performance order, casting by class
Things we explicitly cut from the MVP:
- Multi-location support
- Costume sizing and ordering
- Parent portal (parents would communicate via email until the portal was ready)
- Attendance tracking
- Waiting lists
- In-app messaging
The only hypothesis we needed to test: will dance studio owners pay for a tool that handles enrollment, billing, and recital production in one place? The MVP needed to be functional enough to run a studio. It didn’t need to be complete.
We also made a deliberate choice to build for small-to-mid-size studios (50–300 students) rather than large multi-location operations. The complexity curve on multi-location is steep, and large studios already had enterprise options. The underserved segment was in the middle.
Technical Choices
RecitalDash’s technical complexity is moderate — it’s a relational data problem at its core. Students are enrolled in classes, classes belong to sessions, sessions produce recitals, recitals have performances, performances have a cast drawn from enrolled students.
Python + Django. Same stack we used on StatementPro. Django’s ORM handles the relational complexity well, and the admin interface gives us a backstage tool we can use to manage studios during early onboarding without building separate internal tooling.
Stripe for billing from day one. Tuition billing has nuances — prorated starts, sibling discounts, failed payment handling — that require a real billing system. We built subscription management with line items flexible enough to handle the variations studios actually need.
Recital scheduling as a drag-and-drop interface. The recital module is the one place we invested in front-end complexity. Performance scheduling — ordering acts, managing run time, avoiding conflicts — is inherently a drag-and-drop problem. We built a clean scheduler that studio owners can actually use during production planning meetings without fighting the interface.
Multi-tenant from day one. Unlike StatementPro (which started single-tenant and added multi-tenancy later, a painful migration), we built RecitalDash with proper studio-level data isolation from the start. The StatementPro experience made this a non-negotiable.
Launch and Early Growth
We launched with three studios — the original contact and two from our validation cohort — as paid beta customers at a discounted rate. The criteria for adding new studios: each had to have a recital coming up within six months, so we’d get real data on whether the recital module worked under production conditions.
The first recital produced by a studio using RecitalDash was about eight weeks after launch. It had 22 performances, 180 students, and a scheduling problem we hadn’t anticipated: the director wanted to group performances so that any given student only appeared in consecutive acts, to avoid costume changes crossing a long intermission. We hadn’t built for that constraint.
We built it in two days. That kind of real-world feedback — a constraint you’d never have invented in a spec document — is exactly why early customers with live recitals matter.
By month three, we had nine studios. By month six, twenty-two. Growth was mostly word-of-mouth: studio owners talk to each other at competitions and workshops, and “what software are you using?” is a common question in those circles.
What We’d Do Differently
Build the parent portal earlier. We pushed it to post-launch, thinking email was good enough for parent communication in the MVP. It wasn’t. Parents want a single place to see their student’s classes, upcoming recital information, and billing history. The absence of a portal created support overhead that consumed hours we’d budgeted for new feature development. We built it in month two and the studio owner feedback was immediate: it reduced their inbound parent emails by more than half.
Build attendance tracking earlier. We cut it from the MVP deliberately and correctly — it wasn’t necessary to test the core hypothesis. But studios asked for it immediately, and it turned out to have a retention effect we hadn’t anticipated: studios that used attendance tracking churned at a lower rate than studios that didn’t. The feature deepened engagement with the platform in a way that justified its development much earlier than we’d planned.
What RecitalDash Taught Us
The specific insight from RecitalDash: niche B2B software wins when it solves the one workflow that generic tools get wrong. Every studio management tool handled enrollment. Ours handled recital production — the workflow that happens twice a year, that every studio goes through, and that no competitor had gotten right. That single differentiator drove most of our early adoption.
We also learned something about customer concentration in vertical SaaS: dance studios exist in a community. One happy customer with a good experience at their spring recital is worth more than any paid channel. We underinvested in referral mechanics early on — a simple “refer another studio and get a month free” program would have accelerated the word-of-mouth loop that was already working organically.
If you’re building software for a specific industry vertical and want to work with a team that has been through this process — the validation, the MVP scope, the technical decisions, the growth mechanics — let’s talk.