A dance studio app is a term timetable wrapped around a list of children.
Booking is the easy half. The hard half of a dance studio app is that most of the names in it belong to children, so every screen has to answer a second question: who is allowed to see this. A studio runs on a term timetable, a register taken at the barre, and families who each need their own row and nobody else's. The scheduling part is the same problem as the class schedule apps built for adult students. The rest of it is not.
This page covers what a term of classes asks of an app, who should be able to open a class list, what the children's privacy rules say about photographs, and what the app stores expect. The same answers apply whether you call it a dance school management app or a dance class booking app.
See what each role should seeThe short version
Run the term on a register, and give every role the smallest view that works.
Two things decide whether a studio app is any good. Whether it matches how a term actually runs, with half term gaps, siblings on different levels and make-up classes. And whether a parent who opens it can see anything at all about somebody else's child.
The second is not a setting you add later. It is the shape of the data, and changing it afterwards means going back through every screen you built.
A term is the unit, not the class
Adult fitness software sells single classes. A dance school sells a term. A pupil enrols in Grade 3 ballet on Tuesdays for eleven weeks, not in eleven separate bookings, and that difference runs through the register, the invoice and the waiting list. A studio scheduling app built around one off bookings gets fought every week.
The awkward cases are the normal cases. A pupil takes two classes on the same evening. Her brother takes one. Half term removes a week, so a term is eleven sessions rather than twelve. Somebody misses a month with a sprained ankle and is owed make-up classes that expire. A class fills, and the next three enquiries have to become a waiting list rather than an email nobody answers.
The register is a two second job that has to work in bad light, one handed, with a class waiting. Names, present, absent, late, and a note when a child was collected by a different adult. It should also survive a hall with no signal and sync afterwards.
Fees behave like a subscription rather than a sale: a term paid in three instalments, a sibling discount, a place held over the summer, a family who stops in March and returns in September. Those states are the ordinary business of a membership management app, and they are worth modelling properly, because the alternative is a spreadsheet only one person understands.
Who is allowed to open the class list
A class list is a list of children. Names, ages, where each one is at four o'clock on a Tuesday, and who is coming to fetch them. It should never be one screen that everybody with a login can reach. The default worth starting from is that a parent sees their own child and nothing else, not even the first names of the rest of the class.
Roles do the work. A class teacher needs today's register, the medical notes for the children in front of her, and who may collect each one. The front desk needs who is in the building, who has paid and who to phone. The principal needs the rest, including what nobody else should open: dates of birth, home addresses, and any note about a family arrangement. Photo consent is its own flag and it belongs to the pupil, not the class.
Two details are worth being firm about. Free text notes are where sensitive things get typed and then live for years, so replace the open box with tick boxes wherever you can: allergy, inhaler, do not photograph, collection restricted. And a pupil who leaves should not leave a permanent file behind, so set a date when identifiable rows are deleted and make the app enforce it, because nobody does that by hand.
None of this is work for a later version. It is what protects you when a phone is left unlocked on a kitchen table, when a teacher leaves and her login is still live, or when somebody asks the front desk for an address and sounds sure they are entitled to it.
Try it
What each role should see on the class list
Pick a role. Anything greyed out is something that role has no reason to open, and the safest way to keep it shut is not to send it to that phone.
- ShownYour own child's classes, times and room
- HiddenFirst names of the others in that class
- HiddenFull names and ages of other pupils
- HiddenAllergies and medical notes for today's class
- HiddenWho is allowed to collect each child
- HiddenOther families' phone numbers and addresses
- HiddenPhoto consent for each pupil
- HiddenUnpaid term fees
Parent sees 1 of 8 rows. A parent seeing one row is not a restriction bolted on afterwards. It is the app working.
Photographs of children need a decision, not a toggle
Studios take photographs. The recital, the class on the last day of term, a clip of a correction so a pupil can work on it at home. Every one is a different use, and consent for one is not consent for the others. Ask separately: inside the app for that family, on the studio website, on social media, in printed marketing. Store the answer per pupil and per use, let it be withdrawn, and default a new pupil to no.
It is worth knowing where the American rule lands, because people guess wrong in both directions. The Children's Online Privacy Protection Rule covers online services, including mobile apps, that are directed to children under 13 and collect personal information from children, plus general audience services with actual knowledge they are collecting it from a child under 13. Its definition of personal information includes a photograph, video or audio file where the file contains a child's image or voice. A photo is not an attachment to the record. It is the record.
The other half surprises people. The Federal Trade Commission's guidance says the rule applies to personal information collected online from children, and does not apply to information about children collected online from parents or other adults. A studio app where only staff and parents hold logins is usually not collecting from a child at all. Give pupils their own logins, or somewhere to upload a clip of their solo, and that changes. Take advice for your own jurisdiction, because rules elsewhere are drawn differently.
Sharing is where the consent flag earns its keep. The moment the app can send a photo to a parent it has to know which photo, of which child, to which parents. One group thread is the wrong shape for that: a message to twenty families is a message to twenty phones you do not control. The mechanics are the ordinary problem of a parent teacher communication app, with the consent check in front of the send button.
Getting a studio app onto parents' phones
The app stores hold one surprise, and it is cheap to avoid if you know before you name anything. Apple's review guidelines say apps not in the Kids Category cannot include any terms in the app name, subtitle, icon, screenshots or description that imply the main audience for the app is children. Your users are parents and staff, so calling the listing Ballet For Kids buys a review problem you did not need.
The privacy requirements do not depend on the category. Apple's rules say apps that collect, transmit, or have the capability to share personal information from a minor, with a list that names address, email, location, photos, videos and the ability to chat, must include a privacy policy and comply with all applicable children's privacy statutes. The same section says apps intended primarily for kids should not include third party analytics or third party advertising.
So write the privacy policy before the app rather than after it. It has to say what you hold about a child, who inside the studio can see it, how long you keep it, and who a parent writes to for deletion. Each answer should already be a rule the app enforces, not a paragraph written the night before submission.
What each option gives a studio
| Option | Register at the barre | Parent sees only their own child | Photo consent per use | Bends to your term rules |
|---|---|---|---|---|
| Paper register and a class group chat | Yes | No | No | in your head |
| A shared spreadsheet | if the hall has signal | No | No | Yes |
| General class booking tool | Yes | usually | No | No |
| Studio management platform | Yes | Yes | one flag, not per use | partly |
| An app you build | Yes | Yes | Yes | Yes |
Building one around your own timetable
Studio platforms are priced by the month and shaped around a school with several sites and somebody in the office full time. A studio with four teachers needs a fraction of that, plus three things the platform will not do: the pupil who takes Grade 3 and Grade 4 in the same term, the make-up credit that expires with its term, and the parent allowed to see one of her two children and not the other.
Newly is an AI app builder. You describe the app in plain English, including the rules your term follows and who is allowed to see what, and it writes a real React Native and Expo project you own, runs it on a cloud iPhone or Android simulator while it builds, and ships it to TestFlight and to Google Play internal testing. It costs $25 a month and there is no free plan. It does not process card payments and it is not a studio management platform.
Settle the money before you draw a screen. Whether a term is billed once or in instalments, what a sibling discount does to a refund, and what a pupil who leaves in week six is owed are all decisions about charging for a term of classes, and between them they set half the data model.
Questions people ask about dance studio apps
Four things, in this order. Hold the term timetable and who is enrolled in what. Take the register in two seconds at the barre, including who collected each child. Carry term fees, instalments, sibling discounts and holds. And show each person only what their role needs, which for a parent means their own child and nothing else.
Describe the term your studio actually runs
Write down the levels, the make-up rule and who is allowed to see which child, then build the app around those rather than around somebody else's timetable.
Start building