Kingston Mosque Digital Platform

The project at a glance.

What it does.

How a child joins the Madrasah

1. 01

   Parent registers online

   One family account covers every child, and a home address and two emergency contacts with different phone numbers are required. Registration opens and closes on a schedule the office sets.

2. 02

   Office reviews the queue

   Applications move from received to the waiting list, which is ordered first come, first served within each class group.

3. 03

   A place is offered

   The offer names a class and holds a seat against its capacity, with an expiry date and automatic reminder emails.

4. 04

   Parent accepts in the portal

   Acceptance creates the enrolment, so the child appears on registers, invoices and reports without anyone re-keying it.

5. 05

   Learning and billing run

   Teachers take registers and set homework; parents see attendance, marks and fees; at year end a previewed rollover moves each child up, keeps them in their class or marks them as leaving.

How it's built.

Technology

The hard parts, solved.

1. 01

   Prayer times that must never be wrong

   The mosque supplies a 365-day timetable with daylight-saving changes already applied, so the engine treats every time as London wall-clock time instead of converting it. The importer checks row counts, continuous dates, time formats, the daily order of prayers and jamā'ah outliers, and it caught a slip in the supplied file (one Isha jamā'ah an hour out of line with the days either side) for an admin to confirm. Per-day overrides saved in the admin always win over the annual file.

2. 02

   Children's records handled with care

   Access is split by job: the office runs admissions and registers, safeguarding notes sit behind a dedicated Designated Safeguarding Lead role that general admins and office staff do not have, and management sees aggregate figures without read access to any child's record. The waiting-list export leaves out medical and internal notes, erasure anonymises rather than deletes where financial or safeguarding duties apply, and a draft Data Protection Impact Assessment sets out the decisions left to the trustees.

3. 03

   Money and places that add up

   Invoice runs and lesson generation offer a dry run and are idempotent, so running them twice never double-bills or duplicates a register. Free seats are counted after deducting offers still awaiting a reply, and the year-end rollover is built as preview, commit, safe re-run and undo, with every change stamped with a batch id.

4. 04

   Schema changes on a live database without migrations

   The standard schema push asks for confirmation interactively, which a headless server cannot answer, and one failing statement fails the whole batch. The boot sequence applies the schema without prompts, retries statement by statement if the batch fails, records anything skipped and shows it in the admin, and resynchronises Postgres id sequences so that adding new records cannot fail after a data import or restore.

5. 05

   Failures that announce themselves

   The dashboard raises banners when email cannot leave, when scheduled jobs have gone quiet or when part of the schema did not apply. The scheduled GitHub workflow fails when a job errors or when none of a job's messages could be sent. The spam trap on public forms now flags suspicious submissions for review instead of discarding them, after it was found to be catching real families whose password managers filled the hidden field.