Music School Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the makeup credit rule keep falling outside the software?

Every school this size has a policy. Teacher cancellation is a guaranteed makeup. Student cancellation with enough notice earns a credit. A no show forfeits. Credits expire. There is a cap. That policy is written down, it is fair, and almost no packaged tool can enforce it, because packaged tools bill on a schedule and log attendance separately. The connection between the two is a human.

So the failure repeats: the software is scoped as a calendar plus a payments table, and the credit rule is described as a business process rather than a data model. It gets built as a note field, or worse, as a running count on the family record that anyone can edit. Within a term nobody trusts it, and the front desk goes back to counting.

The fix is to make credits first class ledger entries and to run every lesson through an explicit state machine: scheduled, delivered, cancelled by teacher, cancelled inside notice, cancelled outside notice, no show, made up. Each transition writes a credit row with an issue date, an expiry, the source lesson and, later, the redeeming lesson. Tuition is then computed from the ledger rather than from a static plan, so proration, instrument changes mid term, sibling discounts and withdrawal notice all fall out of one calculation. The parent portal renders the same ledger the front desk sees, which is what actually ends the argument. Self serve makeup booking then only offers slots that are legal under the policy, so a parent cannot book something the school will have to unwind.

What goes wrong when you migrate three years of lesson history and open credits?

Contacts and schedules move cleanly out of My Music Staff, Teachworks or Jackrabbit. Open makeup credits do not, and this is where migrations quietly fail. In most schools those balances were maintained by hand inside attendance notes, so there is no field to map. There is a comment saying owed one from the November snow week, and a different teacher's note saying already used.

Schools that treat this as an import problem end up with two bad outcomes. Either credits are dropped, and every affected family discovers it in the same fortnight, or every ambiguous note is honoured, and you start the new system by giving away lessons you already delivered.

The approach that works is a reconciliation, not an import. Every ambiguous balance is surfaced as a decision with the source notes shown, and your front desk lead approves, adjusts or voids each one. Budget three to six weeks and put a real person's name on it. Then run both systems live for one full billing cycle, compare invoices line by line, and cut over on a period boundary rather than mid month. Anyone who has migrated a live recurring billing business will offer that dual run unprompted. If a developer proposes a weekend cutover on a school that bills on the first, they have not done this before, and your families will be the ones who find out.

Why do the payment, payroll and accounting integrations break after launch?

Three connections carry the money in a music school, and all three fail in ways that are invisible for weeks. The payment gateway is the first. Subscription platforms deliver the same webhook more than once, and a system without idempotency will double post a payment or double issue a credit. It is not a rare event, it is normal operating behaviour, and a build that has not planned for it will produce a family balance nobody can explain.

Payroll is the second. The export runs, someone pushes hours, and a rate change that took effect in October silently rewrites September because the compensation record had no effective date. Teachers notice within one pay period, and pay disputes are the fastest way to lose a good teacher, which in our experience takes fifteen to twenty five students out with them.

The accounting connection is the third and the quietest. Journal entries land at a grain your bookkeeper does not want, so she starts rekeying, and within two terms the books and the system disagree about deferred tuition.

Design for all three explicitly. Every inbound payment event carries an idempotency key so a repeat is ignored rather than reprocessed. Compensation profiles are versioned with effective dates so a raise never rewrites a closed period, and periods lock so nobody edits an April attendance record in June. Ask your bookkeeper what grain she wants before anyone writes the accounting export, because retrofitting that is more expensive than agreeing it in an hour.

What happens when minors' data and teacher messaging are not covered?

This is the gap that gets deferred to a later phase and should never be. Most of your students are children. Student accounts under thirteen bring the Children's Online Privacy Protection Act into scope, which means verifiable parental consent, limits on what you collect and a genuine deletion path, not a hidden flag. Recorded practice submissions and recital video bring a separate consent and revocation problem, because a parent who withdraws consent expects the footage gone rather than unpublished.

The safeguarding side matters more than the compliance side. If teachers can message students directly, you have created an unsupervised channel between an adult and a child, and you have created it by default rather than by decision. Schools discover this the first time a parent asks to see a conversation and nobody can produce it.

Build it into the design. Threads between a teacher and a student include the parent by default and are retained. Roles are real, so a part time teacher at one location cannot browse another location's family list. Background check records and their expiry dates live in the system with alerts, because an expired check that nobody noticed is the sort of thing that ends up in a local news story. Storing cards for autopay also puts payment card compliance in scope, which you avoid entirely by using a tokenising gateway so raw card data never touches your database. A developer who says permissions can be added later is telling you how the rest of the engagement will go.

Should you build custom or configure what you already own?

Configure, genuinely. One location, under roughly 250 active students, a policy that fits on one page and no group programme: My Music Staff, Opus1 or Teachworks is the correct answer and a build is a vanity project. The subscription is a rounding error against a teacher's salary, and you will not out engineer a mature product for the price of a used car. Put the money into teachers and into a decent reminder habit.

Configure harder before you build, too. Most schools running one of these tools have never properly set up their lesson types, notice windows or automated reminders, and a fortnight spent doing that removes more pain than people expect. Ask your vendor what the product can genuinely enforce, in writing, before concluding it cannot.

The build case is specific rather than general dissatisfaction. You are past 500 active students or past two locations. Somebody at your school now has a full time job that is really operating the spreadsheet the software cannot. Your rooms are not interchangeable, because one holds the grand piano and one is the only isolated room, and the platform models rooms as a text label. Teacher pay takes more than a day per period to reconstruct. Or you cannot answer how much prime time capacity is left at one location on a Tuesday without a human counting. Two things settle it outright: if your scheduling or billing behaviour is a genuine differentiator, you cannot rent it, and if you intend to franchise your operating model, you are already a software company.

How do hidden costs get into the quote?

The first is migration, which gets priced as an import and delivered as a reconciliation. Ask for it as its own line with its own weeks, and ask specifically what happens to open credits and to families mid withdrawal notice.

The second is rooms. Typed rooms, meaning instruments present, isolation, capacity, amplification and adjacency conflicts, look optional in a demo and are structural in the code. Retrofitting them later means rewriting the scheduler, so a quote that leaves them for phase two is not cheaper, it is deferred and larger. The same is true of group classes, because term based cohort billing behaves nothing like weekly recurring and schools running both need both models against one family account.

The third is the pieces around the edges that nobody counts as software: payment rails when a legacy vault is involved, multi location resource sharing where two sites share a teacher and a room policy, and mobile apps if you want native rather than responsive. Then the ongoing line, which is roughly fifteen to twenty percent of build cost each year for hosting, monitoring, security patching and the steady stream of small changes your policy generates every September. Hosting itself is minor at music school data volumes. What you are buying is somebody accountable when a gateway changes an interface or your notice window changes. Ask for migration, integrations, mobile and first year support as four separate numbers, and treat a single blended figure as a warning.

What separates a music school build that works from one that fails?

The builds that work model the domain before they draw a screen. Ask any developer to whiteboard the lesson lifecycle including teacher cancellation, student cancellation inside and outside notice, no show, credit issuance, credit expiry, and how each transition touches both tuition and teacher pay. A team that has built this says immutable ledger and state machine without being prompted. A team that draws a calendar table and a payments table will hand you a scheduler, and you will be back in a spreadsheet by year two.

The second marker is that teacher pay is in the first release rather than deferred. It is the highest return piece in the whole build and the one directors most often cut, because it feels like an internal convenience rather than a student facing feature. It is neither. It is the thing that stops your best teachers leaving over a fortnightly argument, and it is the thing that makes payroll a read instead of a reconstruction.

The third is that the school's model wins, not the software's. If you have already tried to bend your policy to fit a product and the school refused, that instinct was correct, and a build that quietly repeats the same compromise has failed before launch. Finally, settle ownership before the first invoice. The repository, the cloud accounts and the gateway keys in your name from the first commit, with the contract saying so, plus an infrastructure diagram and a runbook in scope. Ask what it would cost for your own developer to take the codebase over in year three. A partner confident in the work answers that calmly.