Crescendo: scheduling for a music school's teaching staff.
A teacher management application for a music school, built with Python, Django and Angular. Peripatetic music teaching has an awkward scheduling shape — many tutors, individual pupils, rooms and instruments, and a timetable that changes weekly. This puts the whole thing online instead of in a shared spreadsheet.
The challenge.
- Music teaching is one-to-one and recurring, so the timetable is a dense mesh of individual arrangements rather than a small number of classes.
- Tutors set their own availability and it changes constantly, which makes a manually-maintained timetable wrong almost as soon as it is published.
- A single lesson binds together a tutor, a pupil, a room and often an instrument — a clash on any one of those is a clash on the lesson.
- The people running the schedule are music educators, not systems administrators, so anything requiring technical confidence would simply not get used.
Our approach.
- Modelled the lesson in Django as the relationship between tutor, pupil, time and room, so that every constraint is checked against the same record rather than in separate places.
- Made tutor availability something tutors maintain themselves, which removes the administrative bottleneck that causes the timetable to drift out of date.
- Built the scheduling interface in Angular around the timetable view, because that is how a school actually thinks about its week — the list views exist to support the calendar, not the other way round.
- Enforced clash detection across every dimension at once rather than only on tutor time, since a free tutor with no available room is not a bookable lesson.
- Kept recurring arrangements as first-class objects with exceptions attached, so cancelling one week does not require rebuilding the term.
The outcome.
- The timetable is maintained by the people who hold the information rather than relayed to an administrator.
- Clashes surface at the point of booking instead of on the morning of the lesson.
- Recurring lessons and their one-off exceptions coexist without the term needing to be re-entered.
- Scheduling is done by teaching staff without technical support.
Related education work.
EducationFinlearn: finance & operations academy.
Admins run cohorts in a fraction of the previous effort.
React · Django · Wagtail · PostgreSQL
EducationMoneymaze: financial literacy for a credit union's members.
Learning comes from consequence rather than presentation: participants see how earlier decisions constrain later ones.
React Native · Django · Django REST Framework · Python
EducationEquivoice: Education platform.
A web app for online learning, built with Wagtail, AWS, Python and AWS SES. Courses, submissions, grading and progress live in one platform that learners return to and instructors run without technical help.
Wagtail · AWS · Python · AWS SES
Where AI fits in education.
Tutoring assistants grounded in your course material, feedback drafts that teachers review before release, and course content generated to your curriculum.
Explore AI development“Enigmatix Global did some great work for Sainsbury's, bridging complex interactions between some older less flexible systems, some rigid vendor solutions and the new systems we were building. The software Enigmatix Global developers wrote stood up well, long beyond the interim scope of it needing to work for 12 to 18 months, and was still in active use 5 years after its creation, since it was part of mission-critical systems.”
Questions about this build.
Still wondering something? Ask an engineer
Model the session as a relationship between all its constraints — tutor, learner, time, room, equipment — rather than as a calendar entry with attributes. Once the booking is the relationship, clash detection is a single question asked against one record instead of several checks that can disagree. Getting this wrong is the most common reason scheduling systems allow bookings that are impossible in practice.
Recurrence should be a stored rule with exceptions attached, not a set of individually-created bookings. That way cancelling a single week is one exception rather than an edit that risks the rest of the series, and changing a whole term's arrangement is one change to the rule. The alternative — expanding recurrence into hundreds of separate rows — makes every subsequent bulk change painful.
They have to, or the system fails regardless of how good the engineering is. In practice that means the people who hold the information — tutors with their own availability — maintain it directly, rather than reporting it to an administrator who re-enters it. Any design where accurate data depends on someone relaying it will drift out of date, because that relay step is the first thing dropped in a busy week.
This one uses Python and Django with an Angular front end, which fits well: the scheduling constraints belong in a strong server-side domain model, and the interface is a rich, stateful calendar. The important architectural decision is keeping all constraint logic server-side. Clash rules implemented in the browser will eventually be bypassed, and a double-booking is a much more expensive bug than a slightly slower interaction.
Let's build from here.
Thirty minutes with an engineer who builds. No sales, no drip campaign. If we're the wrong fit we'll tell you and point you somewhere better.