Dance School Software · Enrollment, recital operations, consent-gated media · Early access · 2026

The dance studio platform built for the recital season — enrollment, consent, the command center, and parent-safe media in one place

Dance School Software runs the operations most platforms treat as an afterthought: the recital lineup tied to the live roster and backstage performer check-in (in active development), photo and video proofing organised by class and act with consent-flag suppression enforced at the data layer, and no-skim payout rails for guardian-purchased performance media. Class scheduling, enrollment, and family communications are on the same substrate. The consent layer is not a signed-PDF upload to a folder — it is the spine of every operation. Early access — no pricing commitment, no signup, no live payments today.

Book a conversation How it works

Consent-gated mediaevery photo and video tied to performer-level consent — enforced at the data layer, not by a staff checklist

Roster-driven lineupthe recital lineup builder is in active development — designed to pull from the live roster with no duplicate spreadsheet or manual sync

No-skim payoutsfee off gross first, exact-cent split, largest-remainder reconciliation — no platform margin inserted between parent and studio

Release managementConsent & Release Ledger per student: explicit, time-stamped, revocable, exportable for any date range

The recital season — the studio’s biggest operational event and the sharpest differentiator

A studio with 400 students, 12 acts, and a photo proofing queue that has to know who consented before the photographer leaves the venue

A dance studio running a spring recital has a lineup to build, a backstage roster to manage on the night, and a post-event photo and video proofing run to deliver to families. Each of those operations touches minor students, and each one requires knowing which students have active photo and depiction consent before it runs. Most platforms store consent as a scanned form in an attachment folder. The studio director is the one who has to check the folder before the photographer delivers images.

Dance School Software builds the consent record into the lineup, the check-in, and the proofing queue. The lineup builder maps each student to an act from the live roster — not a duplicate list that falls out of sync. Backstage check-in marks performers present against that lineup as they arrive at the venue. When the photographer delivers images, the platform organises them by class and act and suppresses any image tied to a performer without active photo consent before any staff member has to review a list. The parent who opted in sees a private, time-limited gallery of their child’s performance. The parent who did not opt in does not appear in any gallery, on any device.

The proofing and fulfillment substrate is built and production-ready. The parent-facing storefront checkout is honest-off: not enabled for live transactions today. The lineup builder and backstage check-in are in active development on the built roster and BAS/check-in substrate. Costume and measurement tracking boards are in early access. We say what is built and what is coming because a studio owner making a decision about software deserves to know.

Book a conversation Full platform

How it works

The studio year in four stages

Dance School Software runs on a seasonal rhythm: studio and session setup before enrollment opens, consent collection through the enrollment flow, the recital command center for the performance season, and year-end media delivery with a full records export. Every stage is described as it is built today.

Step 1 · Pre-season — studio and session configuration

Before enrolment opens, a studio director configures the year’s sessions — fall semester, spring semester, summer intensive — each with its own enrolment window, class roster capacity, and level structure. The Consent & Release Ledger template for the studio is defined at this stage: which permissions are required before a student can appear in recital media, which are required for pickup authorisation, which are required for third-party costume vendor data sharing. Instructor assignments and room configurations are set per class. The foundation is the roster: a single source of truth that will drive class assignments, recital lineups, media consent enforcement, and family communications for the rest of the year. A studio sends its existing enrolment export; we return a working studio configured on the platform.

Step 2 · Enrolment — rosters filled, consent collected per student

Families enrol their students through the family portal; each enrolment triggers the consent and release workflow for that student. A guardian cannot complete enrolment without acting on each required consent — giving it, declining it, or deferring it to the studio’s default policy. A declined consent is preserved in the ledger as a valid, explicit record: the student enrols and attends. The roster is the ledger from the first day: every student’s class assignment, consent status, and guardian contact record is in one place before the first class session opens. No family data reaches any communication list until a guardian has opted in. The charge rail for tuition collection is honest-off; billing data is configured and ready for when it is enabled.

Step 3 · Recital season — the command center from lineup to media delivery

The recital command center opens when the first rehearsal schedule is set. Lineup assignments map each student to an act, a class, and an order. Backstage check-in marks performers present against the lineup as they arrive at the venue. Media consent is visible per performer at every stage — in the lineup view, at check-in, and in the post-event proofing queue. After the recital, the photographer delivers media through the platform’s proofing workflow: images organised by class and act, consent suppression running automatically, and the private parent gallery staged for release. The lineup builder and backstage check-in are in active development on the built roster and BAS/check-in substrate; the parent ordering interface is in early access; the proofing and fulfillment substrate is built. The stage manager, the photographer, and the studio director work from one data set.

Step 4 · Year-end — media delivery, records export, and season handoff

Year-end reconciliation covers the recital media commerce run: every order, every payout split, every deletion request logged to the cent. A studio director produces a consent-history export for any student — timestamped records of every permission given, declined, or revoked during the year — in a format that holds up in an inspection or a guardian inquiry. The season export delivers the full record in a portable format: enrolment history, class attendance, consent and release records, recital assignments, and media order history. The organisation owns its data. If a studio ever leaves the platform, every record leaves with it; the one-click export is available in writing as part of the onboarding agreement.

The full platform

Five engines — honest about what is built and what is coming

Every feature is labelled honestly: Built means the underlying engine is production-ready. In development means the surface, wire-up, or checkout integration is in active build. We do not claim otherwise.

Recital command center — lineups, backstage performer check-in, and costume readiness

The recital is the most complex operational event a dance studio runs. Dance School Software approaches it as a command center, not a calendar entry. The lineup builder assigns each student to an act, a class within the act, and an order within the class — tied to the live roster, not a duplicate list in a spreadsheet. A change to the roster propagates automatically: a student who drops before the recital does not require a manual lineup edit. Backstage check-in marks each performer present against their lineup assignment as they arrive at the venue, so the stage manager sees in real time whether the next act is complete. Media consent status is visible per performer in the lineup and check-in views — a student whose guardian has not consented to performance photography is flagged at every stage of the workflow, not discovered after the photos are taken. Costume and measurement tracking boards — which let a studio log each student’s measurements and costume assignment against the roster — are in early access; the underlying roster linkage is built. The lineup builder and backstage check-in are in active development on top of the built roster and BAS/check-in substrate — they are not live today. The full costume-board surface is in active development.

Roster + check-in substrate built · lineup, backstage, costume boards in development

Consent-gated photo and video proofing — organised by class and act, storefront checkout honest-off

Recital photos and performance video are organised in Dance School Software by class, act, and costume — not dropped into a generic event folder. Each image and clip is mapped to a performer from the roster. If a performer does not have active photo consent, that content is suppressed from the proofing view and the parent ordering queue before any human reviews it: consent status is enforced at the data layer, not by a manual staff check. Parents who have opted in see a private, branded gallery of their child’s performance. Share links are time-limited and guardian-scoped: a link generated for one family does not grant access to another family’s child’s images. The print and digital delivery fulfillment substrate is built on the platform’s commerce layer. The storefront checkout is honest-off: the parent-facing ordering interface where a parent browses, selects products, and pays does not yet go live. No-skim payout rails are built; the charge rail that moves money is honest-off alongside the storefront. No image of a minor is ever placed in a public or searchable gallery, and demo content on this site uses fictional students only.

Proofing and fulfillment substrate built · storefront checkout honest-off

Class scheduling, session management, and the family portal

Classes in Dance School Software are organised by session, level, and instructor — each carrying its own roster, schedule, and makeup-class configuration. A family portal shows a guardian their enrolled student’s full class schedule, upcoming recital commitments, and current consent and release status without a phone call to the front desk. Makeup-class scheduling handles the common studio reality of a missed class: a student is placed into a makeup slot that fits their level and does not exceed the room’s capacity. A studio configures session terms — fall semester, spring semester, summer intensive — with different enrolment windows, capacity rules, and roster logic per session. The class scheduling engine and family portal are built and production-ready.

Built · production-ready

No-skim payout rails and tuition billing — exact-cent, charge rail honest-off

The no-skim payout engine for recital media commerce divides proceeds with exact-cent precision: the fee is deducted from gross proceeds first — before any split is calculated — and the studio’s share is calculated on the net remainder. The engine enforces no platform skim between what a parent pays for a print product and what the studio receives. A studio director sees the projected distribution before the charge rail runs. Tuition billing is built at the data layer: billing schedules, invoice records, sibling discounts, scholarship records, and session-based fee structures can be configured. Autopay plan enrolment — the part that initiates recurring charges from a family’s payment method — is in early access. The charge rail that moves money for both recital media commerce and tuition billing is honest-off: present in the platform, not enabled for live transactions today. There is no live checkout, no billing, and no subscription on this site.

Payout engine built · charge rail and autopay honest-off

Who uses it

Built for independent studio owners, school dance programs, and the multi-location studio growing beyond a spreadsheet

Independent studio owners

An independent studio with 100 to 2,000 students runs enrollment, class scheduling, and the recital season on Dance School Software. The Consent & Release Ledger replaces the folder of scanned PDFs. The recital command center replaces the lineup spreadsheet and the backstage clipboard. A studio owner who has been running consent as a PDF upload sees the difference the first time a parent requests a deletion and the record is already in the ledger.

School-affiliated dance programs

A school-affiliated dance program operates within a school’s existing consent framework but runs its own recital and media production. The platform supports school-programme configurations: FERPA-aware posture on student data, adviser-approved publication gates, and media proofing that never exposes an unconsented student. Recital media can feed into the yearbook and the school’s publishing platform without a manual export step.

Multi-location studios

A studio with two or three locations shares one enrollment and consent system, one roster, and one billing configuration, with locations scoped separately. A studio director sees the full picture across locations; an instructor sees only their own classes. Recital command centers can run per location or as a combined event. Multi-location configuration is built at the data layer; the UI surface for multi-location management is in active development. A conversation covers what is available today for a specific configuration.

The Consent & Release Ledger — machine-readable consent at the engine layer

Consent is not a folder. It is the data that drives every downstream operation.

Dance School Software does not store consent as a PDF attachment. The Consent & Release Ledger is a machine-readable record: each permission type (photo/video depiction, social media, authorised pickup, costume vendor data sharing, communications opt-in) is a separate, timestamped, scoped record per student. The platform enforces each record at the engine layer: a student without photo consent does not appear in the proofing gallery, not because a staff member checks a list, but because the system refuses to place them there.

A guardian can revoke any consent at any time. The revocation takes effect immediately: existing proofing gallery entries featuring that performer are suppressed; any queued gallery access is revoked. The revocation is recorded with a timestamp in the audit trail. A director can produce a full consent-history export for any student for any date range — timestamped records of every permission given, declined, or revoked — in a format that holds up in a licensing inspection or a guardian inquiry.

Student and family data is owned by the studio and is never sold to or shared with outside companies. No student image is ever placed in a public or searchable gallery. Share links for private galleries are time-limited and guardian-scoped: a link generated for one family does not grant access to another family’s child’s images. One-click export is available in writing as part of the onboarding agreement: if a studio ever leaves, every record leaves with it.

What is built and what is coming — plainly

The consent and roster engines are built. The storefront checkout and charge rail are not live yet.

Built and production-ready today: enrollment and roster engine; Consent & Release Ledger (explicit, timestamped, scoped, revocable, audit-exportable); class scheduling, session management, and family portal; recital lineup builder (roster-tied, propagates on roster changes); backstage performer check-in; media proofing substrate (consent-flag suppression at the data layer, gallery organisation by class and act); print and digital fulfillment infrastructure; and the no-skim payout engine (fee-off-gross-first, exact-cent, largest-remainder reconciliation).

Not yet enabled for live use: the payment rail (the part that moves money), the parent-facing ordering storefront checkout, autopay tuition plan enrollment, costume and measurement tracking boards, performer-conflict detection, and SMS/text carrier delivery for parent communications. These are honest-off — present in the platform, not enabled for live use. There is no live checkout here. No billing. No subscription. We say this directly because a studio owner deciding between platforms deserves the full picture.

Connected products on the same platform

Dance School Software runs the studio. recital.photos handles the photography. Assembly captures the moment. The yearbook closes the year.

Dance School Software is the studio operating platform: enrollment, consent, scheduling, and the recital command center. recital.photos is the professional recital photography platform: capture workflow organised by act and class, consent-graph delivery, and the proofing and storefront layer for performance media. A studio running both products works from one consent record and one roster: the photographer delivers to the proofing substrate that already knows which performers have active consent. Assembly is the moment layer: live school events captured, archived, and tied to the school’s publishing record. musicschool.software is the sister platform for youth music schools — the same consent-first operating spine, built for the lesson studio and the recital concert. The publishing platform at homeroom.software ties the recital archive into the yearbook, the newspaper, and the performing-arts playbill.

recital.photos assembly.school musicschool.software homeroom.software

Early access · Studio owners, directors, school dance program heads

Book a conversation to see the current state honestly

Dance School Software is in active development. We do conversations that show the current state honestly: how the enrollment and consent flow works, how the recital lineup builder ties to the roster, how backstage check-in runs on the night, how the proofing substrate suppresses images by consent status, and what the no-skim payout engine projects for a recital media run. There is no pricing commitment and no signup. If it looks right for your studio, we discuss what early access looks like.

To book: email [email protected].

FAQ

Common questions

What is built today and what is early access?

Built and production-ready today: enrolment and roster engine, Consent & Release Ledger, class scheduling and session management, family portal, the roster and BAS/check-in substrate, media proofing and fulfillment substrate (consent-flag suppression, gallery organisation by class and act), and the no-skim payout engine. In active development: the recital lineup builder (roster-tied), backstage performer check-in, costume and measurement tracking boards, performer-conflict detection, autopay tuition plan enrolment, and the parent-facing ordering interface. The payment rail — the part that moves money — is honest-off: not enabled for live transactions today. There is no live checkout, no billing, and no subscription on this site. A conversation walks through the current state honestly.

How does consent for recital photos and video work?

Each student has a consent record in the Consent & Release Ledger: photo consent may be given, declined, or revoked at any time by a guardian. That record drives every downstream media operation. When a photographer delivers images after a recital, the platform organises them by class and act. Images tied to a performer without active photo consent are suppressed at the data layer — they do not appear in the proofing view or the parent ordering queue, without any staff member reviewing a list manually. A guardian who revokes photo consent after the recital can request deletion; the request is logged and fulfilled within the stated window. No image of a minor is ever placed in a public gallery or used in marketing without a model-grade release. Demo content on this site uses fictional students only.

Is the parent ordering storefront live?

Not yet. The proofing gallery, the fulfillment infrastructure (print, album, digital delivery), and the no-skim payout engine are built and production-ready. The storefront — the customer-facing interface where a parent browses, selects products, and checks out — is honest-off: the checkout interface that accepts payment does not yet go live. The charge rail that moves money is honest-off alongside it. When the storefront is enabled (a founder-gated decision), the proofing and fulfillment infrastructure it connects to is already in place. We say so directly because studio owners making build-or-buy decisions deserve to know what is live and what is coming.

How do the recital lineup builder and backstage check-in work?

The lineup builder takes the live roster — the same roster used for class enrolment, consent tracking, and family communications — and maps each student to an act, a class within the act, and an order within the class. A change to the roster propagates automatically: a student who drops before the recital does not need a manual lineup edit. Backstage check-in uses the same data: at the venue, a staff member marks each performer present against their lineup assignment as they arrive. The stage manager sees in real time which performers in the next act are checked in. Media consent status is visible per performer in both the lineup and check-in views. These two surfaces — the lineup builder and backstage check-in — are in active development on the built roster and BAS/check-in substrate; they are not live today.

How do the costume and measurement tracking boards work?

Costume boards are in early access. The underlying roster linkage is built: each student record can carry a measurement set and a costume assignment. The board surface — the interface where a studio director sees the full cast’s costume status, flags missing measurements, and marks costumes as fitted and ready — is in active development. When it is available, a studio will be able to track each performer’s measurements, costume assignment, and fitting status in one view, linked to the lineup and the recital command center. Early access participants shape the workflow. We do not claim the costume board surface is available today.

How does the no-skim payout work for recital media commerce?

The no-skim payout engine applies three rules in order: the fee is deducted from gross proceeds first (not buried inside the split); splits are calculated on the net remainder (not on gross, which would inflate the platform’s share); and a largest-remainder reconciliation pass assigns any residual penny to the party with the largest remainder — so the distribution totals to exactly what came in, minus the fee, with nothing coerced into platform margin. A studio director sees the projected distribution before the charge rail runs. The split engine is built and production-ready. The charge rail that moves money is honest-off.

Is tuition billing live?

Tuition billing is at the data layer today. Billing schedules, invoice records, sibling discounts, scholarship and subsidy records, and session-based fee structures can be configured. The invoicing data model is built. Autopay plan enrolment — the part that initiates recurring charges from a family’s payment method — is in early access. The charge rail that processes live payments is honest-off: not enabled for live transactions today. When the charge rail is enabled, the billing data layer it connects to will be in place. A conversation covers the current state honestly and what early access looks like for a studio that wants to be part of the billing development.

How does the Consent & Release Ledger handle different permission types?

The Consent & Release Ledger tracks each permission type as a separate, scoped record per student. Permission types include: depiction consent (photos and video at class and recital); social media consent (whether the studio can post performance content on branded channels); authorised-pickup records (who can collect the student from class); costume vendor data sharing (whether measurements can be sent to a third-party costumer); and communications opt-in (whether a guardian receives studio marketing communications, separate from operational notices). Each record is timestamped. A declined consent is a valid state and does not prevent enrolment. Revoking a consent takes effect immediately and is preserved in the audit trail. A guardian can request a full consent history for their child at any time.

How does the platform handle a guardian who opts out of photos partway through the year?

Revoking photo consent takes effect immediately across every media workflow in the platform. Any existing proofing gallery entries featuring that performer are suppressed; any queued parent gallery access is revoked. The revocation is recorded in the Consent & Release Ledger with a timestamp. If a parent requests deletion of images that were delivered before the revocation, the request is logged and fulfilled within the stated window recorded in the onboarding agreement. The student continues attending class and performing in the recital — the revocation only affects media operations. No image featuring a minor is ever published in a public gallery.

What makes this different from a general studio management platform?

Most studio management platforms are built around billing, class scheduling, and a parent-communications feed — with consent handled as a signed-PDF upload to an attachment folder. Dance School Software is built around the premise that every operation in a dance studio — photos, pickup, costume data, recital media, communications — touches a minor student, and that consent for each of those uses should be explicit, revocable, and enforced by the platform at the data layer. The recital command center — lineup tied to the live roster, backstage check-in, consent-gated proofing organised by act and class, no-skim payout rails — is the signature workflow, not an add-on. Migration is straightforward: send us your enrolment export from your current system and we return a working studio.