Dance Software · for dance programs and studios
The operator home for dance programs: recital scheduling, costume-and-photo day, recital programs, and honest music licensing.
A dance studio or dance program runs picture day, produces a recital program for the audience, schedules individual costume fittings and group photo sessions, maintains class and company rosters, and navigates music licensing for every piece on the program. This platform is built specifically for that combination — not a generic activity calendar, not a repurposed class-roster app. Here is what is built, what is in early access, and what is planned.
Recital scheduling, costume-and-photo day, recital programs, and roster management are built on the shared platform substrate and available in early access. The recital storefront and ticket sales are honest-off — not live today. We say so rather than presenting in-progress work as shipped.
What makes dance programs different from a generic activity
A dance studio or in-school dance program does not run like a sports team or a theatre club. It operates picture day on its own schedule — costume photo sessions are a revenue-bearing event, not a side errand. It produces a printed program for every recital — a publication with casting, music titles, and biographies that goes to several hundred audience members and needs to be right. It works with copyrighted music and needs to be honest about what performance rights it holds. It manages class rosters and company rosters at the same time, with different scheduling rhythms for each. The platform is built around those specifics rather than forcing them into a general-purpose mold.
The distinction from danceschool.software is also deliberate. danceschool.software speaks to a general dance school’s enrollment management, family communication, and front-desk operations. Dance Software is the dance-program and studio operator home, leading with recital scheduling, publication production, and the picture-day operation. The audiences are related but different; the tooling is purpose-matched to each.
What is built
These capabilities exist and run today. The ones marked “early access” are built but not yet available for general use. The full dance-operator command center console is in early access; the underlying substrates are production-ready.
Recital scheduling on both scheduling engines
The schedule.software core provides two scheduling families: the fixed-slot engine (seat-identity model, where each slot has a defined capacity and each booking claims a specific seat) and the window-overlap engine (for facility bookings, rehearsal blocks, and variable-duration events). Recital scheduling uses both: fixed-slot for costume fittings and individual photo sessions where a specific time and changing room are reserved, and window-overlap for rehearsal scheduling and venue holds. A dance director builds the recital schedule once and both engines enforce the logic. The scheduling core is built and powers the schedule.software surface. Built on schedule.software core
Costume-and-photo day as a picture-day operation
Dance studios are picture-day operators. Costume photo sessions are scheduled on the fixed-slot engine: a class or a company is assigned a slot, individual students claim a position within that slot, and the gallery is assembled from the session on the same roster-bound picture-day pipeline used across the platform. Consent is gated per subject, fail-closed: a student’s costume photo is not displayed or offered for sale without consent on file. The branded studio store for parents is available in early access on the built picture-day substrate. The costume-and-photo day operation reuses the same pipeline as school picture day, not a separate system. Substrate built · studio store early access
Recital programs as publications
A recital program is a publication: cast listings, piece titles, music credits, dancer biographies, studio acknowledgments, and the cover. It goes to print. The publications pipeline handles the layout, the content assembly from the roster and the director’s inputs, and the fail-closed print preflight — a program cannot route to print if a required field is missing, a music credit is blank, or a page bleed is out of spec. The same print preflight that gates a yearbook from going to print gates a recital program. The director fills in the program content; the pipeline validates it before the print job runs. Publications pipeline built
Team and roster management for classes and companies
A dance program maintains two kinds of rosters at the same time: class rosters (by technique level, age group, or day-and-time slot) and company rosters (the competition or performance ensembles that draw across class rosters). Both live on the same consent-gated roster substrate with opaque student references and the single-school privacy wall. A director can view a company roster and see which class each member is enrolled in, or view a class roster and see which company members come from this group. The scheduling engine reads both roster types when building a rehearsal block or a fitting slot. Roster substrate built
Music-licensing posture stated plainly
Most dance recitals perform copyrighted music. The recital program lists every piece. Dance Software does not manage licensing for you — that is a legal relationship between the studio and the rights holders. What it does is surface the licensing question plainly: the program builder prompts for a music credit and a performance-right notation for each piece, and the posture statement on the generated program covers what the studio has documented. Pieces from the freeschoolmusic.com library are marked as verified public-domain or open-edition: no performance right required, no per-performance fee, no annual report. For copyrighted pieces, the system records what the studio has documented and makes clear when a field is blank. Posture built · freeschoolmusic editions clean
How recital scheduling works on the two engines
The schedule.software core exposes two scheduling families because recital operations require both. Understanding which engine applies to which part of the recital calendar makes it easier to see how the pieces fit.
The fixed-slot engine is for any booking where the specific slot identity matters: a costume fitting at 3:15 PM in Changing Room B is not interchangeable with a fitting at 3:15 PM in Changing Room A. The slot carries an identity — the room, the photographer, the changing station — and each booking claims a seat within that identity. For dance, this handles costume and photo sessions, individual fitting appointments, and any portion of the recital day where a specific resource is reserved for a specific performer at a specific time.
The window-overlap engine is for bookings where the resource is a facility or a block of time and the constraint is availability: the main studio is available from 4 PM to 6 PM and the rehearsal needs to fit within that window. Rehearsal scheduling, venue holds, and shared-space reservations fit this model. A window booking does not claim a seat identity; it claims a portion of an availability window.
A recital schedule uses both: the full-company rehearsal in the studio is a window booking; the photo session is a fixed-slot booking. Both appear on the same calendar surface and both draw from the same roster to determine who is expected where. A director builds the schedule once; the engine routes each event to the right model automatically based on how the director configured the booking type.
Costume-and-photo day: the full picture-day operation
A dance studio that runs a costume photo session is running picture day. The same infrastructure applies: roster-bound galleries, per-subject consent gates, and a branded store where parents review and order photos. None of this requires a separate photo-management system — it runs on the same picture-day substrate as the school-photography platform.
Scheduling: fixed-slot on the shared engine
Costume photo sessions are scheduled on the fixed-slot engine. A class or company is assigned a block; individual dancers can be assigned specific positions within the block (useful when the photographer needs to move through a planned sequence of setups). The scheduling surface reads the roster to determine who is in scope for the session. Changes to the roster — a dancer moving from one class to another — update the session manifest without a manual re-entry pass.
Capture and gallery: roster-bound, consent-gated
Photos from the costume session are ingested on the platform’s own private system and associated to the dancer’s roster record. A dancer’s costume photo is not displayed in any gallery and is not offered for sale unless consent is on file. The consent gate is fail-closed: an absent consent record is treated as no consent, not as implied consent. A parent or guardian who has not yet consented sees a gallery that tells them their dancer’s photos are on file and available to the studio but not currently displayed or purchasable.
Studio store: early access on the built substrate
The branded studio store for parents — where a parent browses their dancer’s costume photos and places a print or digital order — is built on the picture-day substrate and available in early access. Orders settle on the platform’s own system; the studio receives its revenue leg on every order through the earnings ledger. The ledger routes the studio leg today; the physical payout to a studio bank account is being wired. No dollars reach a studio bank account yet and we say so rather than presenting payout as live.
The recital program as a real publication
A recital program is not a word-processing document that someone prints the morning of the show. It is a publication with a designed layout, roster-sourced cast listings, music credits that need to be accurate and complete, and a print job that has to be right before the show. The publications pipeline handles all of that.
The director fills in the program content through the program builder: piece order, cast assignments drawn from the company roster, music titles and credits, dancer biographies pulled from the roster or entered directly, and studio acknowledgments. The pipeline assembles the layout from that content and the studio’s program template. When the director is ready to print, the fail-closed print preflight runs: a missing music credit, an uncredited piece, a blank biography for a featured dancer, or a page bleed that does not meet the print spec all block the job from routing. The program does not go to print with an error; it goes to print when it is right.
The same preflight that gates a yearbook from printing gates a recital program. The director sees the specific errors and resolves them before resubmitting. Print-ready files route to the platform’s print partner; the studio does not manage the print vendor relationship for the program itself.
Music licensing: what this platform does and does not do
Dance recitals perform copyrighted music. The program lists it. Parents read it. Getting the music credits right and being honest about performance rights is not optional — it is part of producing a real program, and it is a legal matter the studio has to navigate.
Dance Software does not manage music licensing on the studio’s behalf. Licensing is a legal relationship between the studio (or its umbrella organization) and the rights holders for each piece performed. What the platform does is make the licensing question explicit and surface it where it matters: the program builder prompts for a music credit and a performance-right notation on every piece added to the program. If a field is blank, the preflight flags it before print. If a piece is listed without a credit, the program does not route to print.
The one exception is music from the freeschoolmusic.com library. The freeschoolmusic.com catalog is curated specifically to include only works that are either verified public domain or published under an open edition that requires no per-performance fee and no annual licensing report. A piece from the freeschoolmusic.com library is marked in the program builder as clean: no performance right required, no fee, no report. The studio can use it on the recital program with a clear citation and no licensing exposure. For every other piece on the program, the studio is responsible for its own licensing, and the platform records what the studio has documented.
What is in progress and what is planned
These capabilities are not presented as available today. They are named so a dance director or studio administrator considering this platform can see the direction and the honest state of each item.
Dance-operator command center console
The dedicated command center for a dance studio or program operator: a unified dashboard showing the recital schedule, the costume-photo day calendar, open program tasks, roster status by class and company, and the earnings ledger. The underlying substrates are built. The dance-operator console surface is in early access — available to partner studios now, not yet open for general use. Early access
Recital ticket sales (honest-off)
Recital tickets as a revenue line — where a studio sells general admission or reserved seats for the recital through the platform — is on the roadmap. The scheduling and publication substrates are built; the ticket-sales surface and the associated payment wiring are not live today. This is honest-off by construction: the seam exists in the architecture; the wire is not connected. Planned
Competition and adjudication record
A dance company that competes in adjudicated events needs to track results, scores, and placement history alongside the roster. The roster substrate supports this pattern; a dedicated competition-record surface is planned. Planned
Costume and wardrobe inventory
A studio that owns or rents costumes needs to track which costume is assigned to which dancer for which piece, the size and condition of each item, and the return status after the recital. This is distinct from the costume-photo day scheduling — it is inventory management. Planned as an extension of the roster and publication substrates. Planned
Parent communication dispatch
The communication architecture routes outbound messages to consented guardian recipients through the record-notify chokepoint — only guardians who have been identified and consented receive a message. The routing logic and recipient-resolution step are built. The actual outbound dispatch provider is not provisioned today. No message leaves the system until it is wired. Named here rather than buried. Built routing · dispatch honest-off
freeschoolmusic.com catalog expansion
The freeschoolmusic.com library is in active curation. As the catalog expands, more pieces become available for recitals with a clean licensing posture — no per-performance fee, no annual report. A dance studio can browse the catalog and pull a piece directly into a recital program with the clean-license notation already in place. The curation is ongoing; the number of pieces available today is limited. Catalog in curation
Who this is for
Dance Software is for two audiences: the dance studio that runs as a small or mid-size business with its own recital calendar, costume photo days, and program production — and the in-school dance program that operates within a K-12 school and needs to coordinate with the school’s existing roster, consent framework, and print pipeline.
For a dance studio operating independently, the platform provides recital scheduling on the shared scheduling engine, the costume-photo day operation on the picture-day substrate, and the publications pipeline for program production. The studio maintains its own class and company rosters; the platform reads those rosters to build schedules, programs, and galleries without requiring a separate manual entry for each event.
For an in-school dance program, the platform reads from the school’s existing student roster maintained through the K-12 platform. A dancer who is enrolled in the school does not need to be re-entered as a studio student. The consent framework the school has set up for photography and publications covers the dance program’s use of those systems. The same FERPA privacy wall that protects the school’s other student data protects the dance program’s roster data.
This platform is deliberately narrower than instructor.software, which covers directors across all disciplines and is the general activity-and-program layer. Dance Software is the dance-vertical home. If you run a dance program and also manage a theatre production, the theatre-director tools live at instructor.software and freeschoolplays.com; the dance-specific tooling lives here.
Common questions
How is dance.software different from danceschool.software?
danceschool.software is for a general dance school’s front-end operations: class enrollment, family updates, and the recital store for families. Dance Software is the dance program and studio operator home, leading with recital scheduling on the two scheduling engines, costume-and-photo day as a full picture-day operation, and recital programs as publications through the print pipeline. The audiences are related but distinct; the tooling is purpose-matched to each.
Which scheduling engine does recital scheduling use?
Both. The fixed-slot engine handles costume fittings and photo sessions, where a specific room, photographer, and time slot are reserved for each dancer. The window-overlap engine handles rehearsal scheduling and venue holds, where the constraint is a facility’s availability window rather than a specific seat identity. A recital schedule uses both engines; the director configures each booking type and the engine routes it correctly.
Can we run the costume photo session ourselves without a studio photographer?
Yes. The picture-day substrate supports the studio-run, self-operated model as well as a contracted-photographer model. A studio that has its own photographer runs the costume session on the same pipeline and retains the full studio leg of the order split. The platform provides the scheduling, the consent gate, the gallery, and the store; the studio provides the photographer.
Does the platform manage our performance licensing for copyrighted music?
No. Licensing is a legal relationship between your studio and the rights holders for each piece. The platform makes the question explicit: the program builder prompts for a music credit and a performance-right notation on every piece, and the print preflight blocks the job if a credit is missing. For music from the freeschoolmusic.com library, the platform marks the piece as clean — verified public domain or open edition, no per-performance fee. For all other pieces, the studio documents what it has arranged and the platform records it.
What is the fail-closed print preflight for the recital program?
The print preflight is a validation step that runs before a program routes to print. It checks that every piece on the program has a music credit, that every cast entry has a dancer assignment, that no biography field is blank for a featured dancer, and that the page layout meets the print vendor’s bleed and margin spec. If any check fails, the program does not route to print — the director sees the specific errors and resolves them before resubmitting. The preflight is fail-closed: a missing field is treated as an error, not as an acceptable blank.
Can a recital program include pieces with music from freeschoolmusic.com?
Yes. A piece from the freeschoolmusic.com catalog is marked in the program builder as clean: the platform records the attribution and the open-edition or public-domain status, and the program cites it accordingly. The studio does not need to obtain a separate performance license for a freeschoolmusic.com piece. For pieces not in that catalog, the studio is responsible for its own licensing documentation and the platform records what the studio has entered.
Is the recital storefront for ticket sales live today?
No. Ticket sales and a public recital storefront are on the roadmap but are not live today. This is honest-off by construction: the platform names the seam rather than hiding it. The scheduling and publication substrates are built. The ticket-sales wire is not connected. No ticket revenue flows through the platform today.
What does “honest-off” mean?
It means the feature or integration is built in the architecture but not live: the code has the seam, but a dependency — an outbound provider, a payment wire, a third-party connection — is not yet connected. Honest-off is how this platform names those seams rather than presenting early work as finished.
Can an in-school dance program use this without the studio setting it up separately?
Yes. An in-school dance program that operates within a K-12 school using the platform reads from the school’s existing roster. The school’s consent framework covers the dance program’s use of photography and publications. The dance director gets access to the scheduling, program, and costume-day tools through the school’s platform configuration without a separate studio account.
Is student or dancer biometric or facial-recognition data collected?
No. The costume-and-photo day operation uses roster-based association: a photo is linked to a dancer through the roster record, not through a face match or biometric template. Facial recognition is off by default on all picture-day surfaces and is not used to associate costume photos to dancers. The standard costume-and-photo day path computes no biometric template. Face matching is a separate per-child opt-in feature that is off by default, and it takes two separate locks to switch on: the consent gate has to permit it, and an explicit opt-in has to be on file for that dancer. When it is on, the face template is held only inside our own private system, with no outside recognition service connected to it, and withdrawing the opt-in stops the matching at the gate. The school’s face-data retention window (365 days by default) is what marks that template due for destruction; the step that destroys it is not finished, and we are not going to tell you a template is deleted when we cannot show you that it is.
Related properties
schedule.software
The scheduling core that recital scheduling runs on: fixed-slot and window-overlap engines, the same two families used for every K-12 booking surface on the platform.
recital.photos
The recital-photo-day angle specifically: consent-gated recital photography, roster-bound galleries, and the parent-facing storefront for recital photos.
freeschoolmusic.com
The free music library for school and studio programs: verified public-domain and open-edition scores with no per-performance fee and no annual licensing report. The catalog that backs the clean-license posture on Dance Software recital programs.
instructor.software
The platform for directors, coaches, and advisors across all disciplines — not just dance. If you run a theatre production alongside a dance program, the director’s-note engine and rehearsal planning tools for theatre live here.
What is built, what is in early access, and what is honest-off
Recital scheduling on both the fixed-slot and window-overlap engines, costume-and-photo day on the built picture-day substrate, recital programs as publications with fail-closed print preflight, team and roster management for classes and companies, and the music-licensing posture tied to freeschoolmusic.com are built on the shared platform substrate. The dance-operator command center console is in early access — available to partner studios and programs, not yet open for general use. The branded studio store for parent photo orders is in early access; the studio-leg payout to a bank account is the fast-follow being wired. Ticket sales and a public recital storefront are planned, honest-off: the seam exists; the wire is not connected; no ticket revenue flows today. Parent communication dispatch is built on the routing side; the outbound provider is not yet connected. We say all of this plainly rather than presenting in-progress work as finished.
Dance Software is part of the Stanley Studios K-12 platform: one consented student record underneath, one print pipeline, one scheduling core — purpose-matched to the dance vertical.