Systems that survive their users.

Leave management

Before: a different form for every leave type — download, print, sign, submit — and HR kept the hardcopies, counted balances by hand, chased medical certificates, compiled every report MOE requested. Now: one page shows every leave type at once, eligibility beside used beside balance, next to everything adjacent to leave that used to live in its own paper trail — official school duties, time off, travel declarations. The system knows the rules: a shared 14-day family-leave pool across ~48 leave types, per-category caps, childcare entitlements computed from each staff member's declared children and their ages, day counts that skip holidays and term breaks automatically.

Approval is two people, not one: a Supporting Officer signs off first, an Approving Officer second, each stamped with their own timestamp — so a request's state is never a guess. Medical certificates upload straight into the row they belong to, and a missing one is a system reminder chasing the staff member, not HR chasing an email. MOE's reports are generated, not compiled.

What "encoding the rules" actually looks like: apply under childcare leave and the form doesn't just ask for dates — it shows the bracket a staff member falls into, by number of children under 12 and whether all of them are already 7 or older, and computes the annual cap on the spot — the live form is in the screenshot below. The hard part was never the form — it was encoding entitlement rules precisely enough that staff and HR stopped negotiating them case by case.

Delivery pipeline & monitoring

Built from zero on a system that had no version control: self-hosted git with a pre-receive gate that blocks secrets, credentials, data extracts, encoding corruption, and syntax errors before anything publishes. Staging deploys itself on every push, in seconds; production moves only when a person approves a release — continuous delivery, deliberately not continuous deployment, for a live system holding student data. Beside it: log shipping and dashboards with alert rules that email on brute-force, scanning, and injection patterns — plus a written OWASP Top 10 assessment stating plainly what the setup catches and what it doesn't, because a security posture you can't state the limits of isn't one. The stated limit today: detection over prevention. The next layer — an edge WAF and DDoS shield — is costed, proposed, and awaiting its turn in the budget cycle. Fittingly, that funding request lives inside the budget workflow of the previous entry: the roadmap governs itself through the systems on this page.

The loop is fully closed — and nothing on a server ever needs a shell. The gate runs itself on every push; staging deploys itself; production is a button pressed by one of three approvers; even database migrations apply from a browser page. The runbook lives in markdown beside the code — so the whole operation is one a colleague, or an AI session, can pick up cold.

For a beginning: the same pipeline is now extending to a from-scratch rewrite of this whole system — same staging-then-approved-production shape, now with an automated test suite, a dependency-vulnerability audit, and a style check, all running on every push. Today the suite is six cases pinning the login wall's exact shape, so a route can't silently go public — and the audit found 12 real advisories in third-party packages on its very first run. Small start; more lands as the rewrite grows.

The observability half is partly hand-built: an APM-lite where clicking any moment on the charts opens the requests around it — per-script hits, durations, bytes. "What caused that spike" is one click, not a log dive.

platform drill-down incidents

Event management

Before: running an event meant notifying every party by hand — a paper trail to Facilities for the venue, a separate email to AV for the projector and mic, a PG form on its own track for approval, a spreadsheet for who's coming, and a sign-in sheet nobody later reconciled against anyone's training record. Now: staff key an event in once, and the form doesn't just collect information — it decides who else needs to know.

Mark that the event needs a PG form and it routes for approval before anything else proceeds. Mark that it needs AV or Facilities support and the request emails straight to the department that owns it — no separate ticket, no chasing a reply. Mark it a training event and the system generates a QR code on the spot: scanned at the door, it records attendance and writes straight into that staff member's personal training-hours record — the same scan-is-the-transaction idea proven below, in production a second time. Mark that it needs a room and the event creates its own room-booking record instead of a parallel request typed in twice.

Every event, once declared, surfaces on the school's home page — one shared calendar, not five separate inboxes to check. And the department on the receiving end of most of these routed requests, AV and Facilities, gets its own support calendar dashboard: every request that named them, in one place, instead of buried across individual emails.

Same idea as leave management, one entry up: the intake form is the orchestration engine. One decision by the organiser — what kind of event this is — silently triggers exactly the downstream systems that decision implies, instead of asking them to know and notify each one themselves.

home page support dashboard PG form room & support

Where the system meets the physical world

Three of the same idea — the scan is the transaction, no forms, no typing at the counter:

Equipment loans. Before: a paper sign-out sheet at the loan desk — handwriting hoped to stay legible, a hostname copied out by hand, no real trail once the sheet filled up or went missing. Now: scan the borrower's NRIC, scan the item's barcode — loaned. Scan again — returned. The ledger writes itself: who, which serial number, when it left, when it came back — queryable, not flipped through. The reader stack shows its own iteration: a barcode scanner for the NRIC and the item tag, an RFID reader sitting right beside it, added once tap-based returns turned out faster for some items than hunting for a barcode. Whatever's fastest to scan wins; the ledger doesn't care which reader wrote the row.

Collections by RFID. Staff tap their card; the pickup is recorded to their name in the same motion that hands them the item. Nobody signs a sheet that someone else must later type in.

Open house check-in. Registration generates a QR; at the door, a student helper scans it and instantly sees which sessions the visitor registered for — and guides them accordingly. The helper needs no training beyond "point and scan."

The metric that matters: nobody is ordered to use these — the departments come back and book them again every year. Recurrence by choice is what surviving your users actually looks like.

loan desk ledger RFID reader collections open house

This site

Hand-built, no framework: a token-driven design system with full light/dark theming, a runtime chroma-key that removes a video background pixel-by-pixel in canvas (despill plus a two-pass edge erode), four wireframe objects drawn and rotated in ~150 lines, synced to a video loop. Built in collaboration with an AI, with the human owning every design decision — which is rather the point of the whole site.