School and learning platforms
Enrolment, timetabling, attendance, assessment and the record a student accumulates across years — or, for a training business, courses, cohorts, payment and completion. Related shapes, different systems.
Talk about scopeTwo things get called an LMS, and they are not the same build
A school runs on compulsory enrolment: a fixed roll, a timetable that must not double-book a room or a teacher, statutory attendance, and a record that follows a child for years and is handed to another institution at the end of it. Almost none of that is optional, and the hard parts are scheduling and permanence.
A training business runs on the opposite: people choose to enrol, pay, may not finish, and may come back for something else. The hard parts there are payment, access control and proving completion. Building either one on the other's assumptions is the mistake that costs a rebuild, so the first question we ask is which of the two this is.
- Mrs Rahman already teaches 11A in P2
- RM 204 seats 24; 10B is 31
- 10B has PE in P2 on the cohort timetable
- Chemistry needs a lab, and both labs are taken
What we would build
A timetable is a constraint solver wearing a grid
A class needs a teacher who is free, a room that is free and big enough, at a time the cohort is available, for a subject that teacher can teach. Change one and the conflicts cascade. Software that presents this as a spreadsheet pushes the solving back onto a person with a whiteboard every term — the value is in detecting and explaining the clash, not in storing the result.
The record outlives everyone who entered it
A student record is read years later by staff who were not there, and sometimes by the student as an adult. Marks are amended, subjects are dropped mid-year, names change. Everything is versioned with a date and nothing is overwritten, because the question asked later is not just what the grade was but what it was at the time and who changed it.
Where these systems usually fail
- A timetable clash the software allowed and a person found.
- Attendance that is easy to record late and impossible to correct.
- Parent access bolted on, so it can see more than it should.
- Marks entered in a spreadsheet because the screen was slower.
- Last year's cohort inaccessible after the roll-over.
- Payment and enrolment stored apart, and quietly disagreeing.
When not to build this
A packaged product is the right answer more often than a development company usually admits, and if your problem is an ordinary one that something off the shelf already solves, we will tell you so rather than quote for it. What follows is the case for the other answer — the conditions under which building is worth what it costs.
The workaround has become the process
A packaged system that mostly fits leaves a residue — the spreadsheet kept alongside it, the step done by hand every month, the field used to mean something it was not named for. When that residue is where the actual work happens, you are already maintaining custom software, just without any of the benefits of having built it.
The thing you do differently is the thing it cannot do
Every business has a few processes that are genuinely its own, and those are usually the ones it competes on. Off-the-shelf software is built for the average of a sector, so it handles the ordinary parts well and the distinctive part not at all. Building is worth it exactly where that overlap fails, and rarely anywhere else.
A vulnerability shared by every deployment
A vulnerability in a packaged product is a vulnerability in every deployment of it, and attackers only have to find it once. A system built for one business is not on that list.