Scheduling, families, consent, and recital season — the operating platform built for a youth music school

A consent ledger is a per-student record of every permission a guardian has given, withdrawn, or not yet answered. In a music school context that means: the photo and video release that governs whether a student’s image can appear in a shared gallery or on a programme; the communication opt-in that governs whether the studio can send a family a newsletter or a billing notice; the pick-up authorisation that controls who can take the student home after a lesson. These are not the same thing, and the ledger treats them as separate items. Consent is not assumed from enrollment. It is collected explicitly, time-stamped, and revocable. When a guardian revokes a permission, the effect is immediate: the student’s image does not appear in the next gallery export, and the family does not receive the next communication batch.

Not yet. The billing records model — the data layer that holds tuition plans, billing periods, late fees, receipts, and tax-statement generation — is built. The live billing surface that runs a billing cycle, sends a statement, and records a payment is in active development. The charge rail that moves money is honest-off: it exists in the platform but is not enabled for live transactions today. There is no live checkout, no billing subscription, and no payment processing active. When the charge rail is enabled — a founder-gated decision — studios will be notified. The CTA here is “book a conversation,” not “sign up and pay.”

The recital workflow has three phases. Before the recital: the programme builder — in active development — assembles act order and performer lists from the roster, checking consent status for every name before producing a programme PDF. A performer whose guardian has not consented to public listing is excluded from the programme automatically. At the recital: backstage check-in — also in active development — confirms performers present and flags any guardian pick-up notes against the consent record. After the recital: media is uploaded to the consent-gated gallery. Only performers with an active media-consent record appear in the gallery or in any purchasable product. Families receive a private link, browse their gallery, and select photo packages. Fulfillment is handled by the platform. The gallery and fulfillment substrate are built and production-ready; the programme builder and backstage check-in surface are in active development.

Send the platform team your enrollment spreadsheet or an export from your current system and we return a working school: students matched to teachers, guardian contacts imported, consent forms sent to families, lesson schedules drafted. Migration is a service, not an afternoon of data entry. The “send us your spreadsheet” offer is real: the import engine handles common formats from scheduling tools, studio management platforms, and standard spreadsheet exports. If your data is in a format we haven’t seen, we work it through manually. The goal is to make the transition cost close to zero for a school of a hundred students. Migration scope and timeline are covered in the onboarding conversation.

The scheduling engine manages lessons at the teacher and room level simultaneously. Each teacher has their own availability, and the room booking calendar prevents double-booking. A student’s lesson history — attended, cancelled, made up — lives in their record. The lesson make-up calendar — where a cancelled lesson generates a make-up slot that can be offered and accepted without re-entering data, under a studio-level make-up policy (how many make-ups per semester, how far out they can be scheduled, whether a no-show counts) rather than a hard-coded rule — is in active development on top of the scheduling substrate. The teacher-availability and room-booking scheduling engine is built and production-ready; the make-up calendar is not live today.

Instrument-rental tracking is early-access. The records model tracks what the studio has loaned to which student, on what date, and the expected return. A studio with twenty loaner violins and a rolling rental list knows at any moment which instruments are out and to whom. The tracking surface, the return-due notifications, and the rental terms record are in active development. When instrument-rental tracking ships to general availability, it will sit on the same student record as consent, scheduling, and billing — so the rental history is part of the student’s full account, not a separate log kept in a drawer.

Teacher lesson notes and student progress tracking are early-access. A teacher writes a short note after a session — what was covered, what to work on before next lesson — and the note is visible to the family inside their account. Progress tracking records milestones: the pieces a student has completed, the technique benchmarks they have passed. These are visible to the family as a running log, not just the most recent lesson. The lesson notes and progress tracking surface are in active development on the same consent-first student record. We describe them as early-access because that is what they are: the data model is built; the teacher-facing note UI is in active development.

Media consent is a separate, explicit permission in the consent ledger. A family’s enrollment does not imply consent to recital photography. The family must explicitly opt in — or the student’s image does not appear in a shared gallery, on a printed programme, or in any purchasable product. This is enforced at the gallery and storefront layer: when media is uploaded to the platform, the system checks the performer’s consent record before including them in any shareable link or print product. A photographer or studio admin cannot override this check by uploading an image — the consent gate is at the data layer. If a guardian revokes consent after a recital has already been photographed, the student’s images are removed from the active gallery and are not available for purchase.

The platform is in active development. In a demo we walk through the current state honestly: the enrollment engine importing a student roster with guardian contacts; the scheduling engine building a weekly lesson grid with room assignments (the make-up calendar is in active development); the consent ledger showing photo, communication, and pick-up permissions per student; the consent-gated gallery receiving recital media and filtering by consent status before producing a family storefront. None of the payment, billing, or checkout interfaces are enabled for live transactions today. A conversation is the honest next step — we show what is built, what the development timeline looks like, and what early access means for your studio.

The no-skim payout engine applies three rules in order when a family buys a print or gallery product: the platform fee is deducted from the gross amount first, before any split is calculated; the split is applied to the net remainder, not the 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 total always equals exactly what came in minus the fee. There is no platform skim: nothing is inserted between what a family pays and what the studio receives beyond the stated fee. The payout engine is built and production-ready. The charge rail that moves money is honest-off — not yet enabled for live transactions.

The platform is built on a COPPA-conscious, FERPA-aware architecture: no behavioural tracking on minors, no third-party ad networks, no data broker sharing, no public-facing student profiles or searchable rosters. The studio owns its family and student data. It is never sold or shared with outside companies or advertisers. Students’ photos, lesson records, and consent histories are not visible to other families. The platform runs on private infrastructure. One-click data export is available in writing — if a studio ever leaves, every record leaves with it: student histories, consent logs, gallery records, lesson notes. This guarantee is part of the onboarding agreement, not a footnote. We do not claim SOC 2 or FERPA certification; we describe our architecture honestly and publish the specifics.