One school's system, rebuilt as a product

Enrolio started life as a bespoke platform for one franchised stage school. It ran the registers, took the payments and managed the classes, and it worked well enough that its owner noticed something: every other school in the sector had the same problems and nothing good to solve them with.

The trouble was that the system had been built for exactly one company. Franchise data shared a single database. Signing up made a user an administrator of the whole platform. Commission logic was bolted on the side. Nothing about it was ready to be sold to a competitor of the business it was built for.

So the job was not to add a signup form. It was to turn a working single-tenant application into a product, without taking the business that ran on it offline.

A school signs up in the admin system and a company is created. A shop subdomain is provisioned and served over HTTPS. Brand colours and logo come from that company's own configuration. Sectors, disciplines and levels are set in an onboarding wizard — ballet down to grade one, gymnastics to its own levels, whatever the school actually teaches.

Underneath, tenancy is enforced in two directions. Public shop traffic resolves its company from the request origin and is refused outright if the domain is unknown. Authenticated traffic carries an active company claim in its token, and every read is scoped through it.

White labelling runs through all three front ends. Each carries a brands directory and per-brand configuration, so colours, logos and assets change without anyone forking the codebase.

The role model was rebuilt alongside it: seven roles from company owner down to chaperone, seventy-seven permissions mapped across them, and every endpoint checked against that map rather than against a comment in the code.

The admin system is where a school is configured. The app is where the week actually happens, and it is used by a teacher holding a phone in a hall with twenty children, no free hands and bad wifi. That constraint decided most of the design.

Registers run by stage and class group with sign in and out. Assessments sit on a skill tree — skill families down to individual skills, each scored across five measurements, with soft skills recorded alongside and a drafted note home the teacher can edit. Photo and video upload is blocked outright for any student without photographic permission on record.

The parent and teacher app is a progressive web app that is also the iOS and Android build. One codebase installs to a home screen from the browser and ships to both app stores through a native wrapper, which is the only way a team this size keeps three platforms in step.

Local state lives in the browser's own database, with native SQLite on device. The service worker precaches the shell and — the part that matters — runs a background sync queue that captures writes which fail offline and replays them when the connection returns.

A register taken in a basement is not a register lost. That was the whole requirement, and it drove the storage design more than any feature on the roadmap.

Schools lose families quietly. A parent who cannot see what their child is doing eventually stops paying for it. The journey turns a term of teacher assessments into something a parent can scroll: skills progressing, milestones unlocked, achievements earned, and moments shared from the class as a photo, a video or a voice note.

Around it sits the ordinary machinery a school runs on: booking classes, camps, session packs and one-to-ones; subscriptions, trials, sibling discounts and coupons; announcements and chat with the school.

This platform holds records for children: names, dates of birth, medical notes, who is allowed to collect them and who is allowed to photograph them. That shapes a build more than any feature list does.

Photographic permission is a property of the student, and it disables the upload control itself rather than being a policy a teacher is expected to remember at the end of a busy class. Safeguarding concerns go through their own flow — a note, a photo or an audio recording, routed to the people who are supposed to see it. Access is role-based throughout, so a chaperone, a teacher and a company owner each see a different version of the same child's record.

The screens on this page were rebuilt for publication with invented names, initials instead of faces and an illustrated stage in place of a class photograph. No child appears anywhere on it. That is the same instinct the product is built on, applied to a web page.

Enrolio is live. Two schools were migrated onto it in August 2026 as separate, isolated companies, and the first billing run went through production on the first of September, charging a hundred and seventy-three subscriptions. More schools are in the pipeline.

The product belongs to its owner, not to us. Our part was the build: the API, the admin system, the app, the shop, the re-architecture that made it sellable, and the migration that put real schools on it.