Language School Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does enrollment get modelled as a subscription so often?

Because payment tooling pushes you there. Stripe Billing and similar products model a recurring charge against a customer, and that fits a gym or a software product perfectly. A language school looks close enough at a glance that a generic development team will build it that way without asking.

Your revenue is not monthly, it is cycle based, and the unit that carries the money is a place in a specific group. A student pays $1,400 for a ten week cycle, or four installments, or their employer pays for six of twelve people on a corporate contract while the others pay themselves, or they froze for a cycle because of a work trip and are owed a credit. None of that is a subscription against a person.

The fix is to make the seat the unit before any code exists. A seat in a cohort has a price, a payer who may not be the student, a payment plan, and a state: held, confirmed, active, frozen, transferred, refunded. Payments attach to seats, and a transfer moves the paid balance with the seat. Corporate contracts become their own object with a funded seat pool, a purchase order number, an invoicing cadence and a named contact who receives the attendance report that justifies renewal.

What goes wrong when you migrate five years of student and level data?

The volume is never the problem. The quality is. Level was a free text field, so somebody typed variations on B1 and B2 several hundred times, including things like high A2. Placement scores were recorded inconsistently across three instruments. Attendance exists as percentages with no underlying session records. Payments were reconciled by hand and no longer tie to a cohort, so revenue by cycle cannot be reconstructed with confidence.

The second problem is students who exist several times. Someone enrolled under a passport spelling, returned two years later with an email address, and the two records carry different levels and separate payment histories. Merging them is a judgement call per student, not a rule, and getting it wrong produces a progression history that never happened.

In our builds, data migration in this category routinely runs 15 to 25 percent of a first release, and it is always underestimated. The way to avoid the surprise is a data audit in week one, before anyone commits to a timeline. Then migrate deliberately: normalise levels against a documented mapping your Director of Studies signs off, bring across active students, current cohorts, open balances and corporate contracts in full, and archive older history as read only records rather than reinterpreting it. Duplicate resolution needs a review queue with a human deciding, before go live rather than as cleanup afterwards.

Why do the payment and messaging integrations break after launch?

Installment failures are the first and most damaging. A payment fails in week 6 of a ten week cycle. What happens next is a business decision nobody makes during the build, so the software makes it by default: the seat stays active silently, or it deactivates and the student turns up to a class they are no longer enrolled in. Both generate a support ticket every week forever. Ask a developer what happens on a failed installment mid cycle, and who gets told, before you sign anything.

Accounting is the second. Revenue recognition across cycle boundaries is awkward, because money received in March pays for teaching delivered in April and May. If the integration pushes cash rather than earned revenue, your accountant rebuilds it in the spreadsheet you were trying to retire.

Messaging is the third and it fails quietly. Re-enrollment nudges and at risk outreach depend on lists, and a list that stops syncing looks exactly like a quiet week, so a cycle goes by without the outreach that recovers students.

The fixes are unremarkable. Make the failed payment path an explicit product decision with a written rule per account type. Reconcile a daily total between the payment provider and your own seat ledger and alert on any difference. Alert on absence for outbound messaging, not just on errors. Keep the payment provider's reference on the seat record, so a refund three months later can be traced without a support conversation.

What happens when visa and accreditation reporting are not covered?

You find out during an audit, which is the worst moment, because the finding attaches to the school rather than to a student. If you take international students, attendance thresholds tied to visa status, enrollment confirmations and hour verification for accreditation bodies are obligations with consequences. Generic tools give you an attendance percentage, which is not the rule your accreditor or immigration authority actually applies over the period they use.

The mechanical failure underneath it is that attendance is captured on paper and typed in on Fridays, so by the time a trend is visible the reporting period is closed. Nobody can tell you on day 12 that a student is heading toward a breach, because days 1 to 11 have not been entered yet.

The fix has two halves. Capture attendance at source, in a teacher app, in the room, in under ten seconds, with an offline queue because basement classrooms have no signal. Then codify the compliance rule with its exact definition and reporting period, run it nightly, and raise a flag while there is still an intervention window, with an audit trail showing who was notified and when. Test a developer's instinct on this: the right answer starts with questions about which authority, what definition of attendance, what reporting period and who is legally accountable. An answer that starts with adding an attendance percentage means they have not built one.

Should you build custom or configure what you already own?

Stay on what you have if you are a single location under roughly 400 active students with fixed term starts. Classe365 or Teachworks will hold your records perfectly well, your Director of Studies can build a dozen sections by hand in a morning, and a custom build would buy a slightly nicer version of a problem you do not have. Spend the money on teachers.

The trigger is not student count, it is whether your operating logic has left the software. The moment your real placement and cohort rules live in a spreadsheet and in one person's head, the school tool has become a filing cabinet, and every additional student makes it worse. At that point you are already paying for custom software, in your Director of Studies' salary, in reconciliation hours, and in the re-enrollments that leak whenever someone gets phoned and asked to move class.

Build when three of these are true. Your Director of Studies spends more than two full days per cycle building the grid by hand. You run continuous intake so there is no quiet week where everything resets. You operate two or more locations with teachers shared across them. Your re-enrollment rate between cycles is a number you cannot explain because the data sits in three systems. You have corporate contracts where the payer is not the student. Or you employ someone whose real function is reconciling the school tool against the payment provider.

How do hidden costs get into the quote?

Four places, and the first is the solver. If your scheduling constraints are simple, cohort building is about a week of work. If you have teacher seniority rules, room equipment requirements, split level classes, travel buffers between sites and per room priority rules, it is a month and it needs tuning against real historic cycles rather than synthetic data. Ask for the solver to be quoted separately against your actual constraint list.

Data migration is the second and routinely runs 15 to 25 percent of a first release. Get the audit before the estimate.

Compliance surface is the third. Reporting to an immigration authority or an accreditor is a rule you must be able to defend, with its own build and test cycle, not a report added at the end. Multi currency and multi country is the fourth, and it turns billing from a component into a workstream. If your locations cross borders, say so in the first conversation, because tax handling, payment methods and refund rules all diverge and none of that is a configuration flag.

What separates a build that works from one that fails here?

The builds that work keep the human in control of the schedule. A solver proposes a grid scored explicitly on first choice placements, second choice placements, unplaced students, sections below minimum, teacher hours utilisation and room utilisation. The Director of Studies drags two sections, the system re-solves only the affected students in under a second, and tells her who she just displaced. Three days becomes an afternoon and the grid is better, because a solver will discover that one extra Saturday morning section rescues nine students who would otherwise have churned.

The builds that fail hand over an algorithm and call it automation. The Director of Studies refuses to use it by cycle two, goes back to the spreadsheet, and the project becomes a filing cabinet with better styling. A team that has shipped this talks immediately about proposal and approve flows, re-solving only affected students, showing who got displaced, and keeping an override log. That log matters more than it sounds, because after four cycles the good overrides become rules and the placement instrument itself gets fixed.

The same principle governs where AI belongs. An after hours placement conversation that probes vocabulary range, tense control and error patterns and produces a draft CEFR sub score breakdown plus a transcript is genuinely useful, and your Director of Studies approves it in about ninety seconds. The approval is what writes to the placement record, and keeping the human in that step is what makes it defensible.

Settle ownership in writing before work starts: full source, repositories, infrastructure accounts and data, handed over in a deployable state with documentation. Any developer who wants to retain ownership or gate you behind their hosting is selling a product with extra steps, which is what you were leaving.