2025 — 2026· frontend
Preschool management for three audiences at once — owners, teachers and parents — including a shared tablet at the front door that strangers use one after another.
I designed and built the kiosk mode, the admissions pipeline, room activities across all three role surfaces, leads and requests, and the subdomain tenancy that separates one school from another. Colleagues layered UI onto several of those files afterwards, so line-level blame under-credits the logic — but the commits that first introduced each mechanism are mine. One exception worth naming: the offline attendance queue that makes the kiosk survive bad wifi was written later by a colleague. I opened that problem, and someone else solved its hardest half.
A preschool runs on three completely different relationships with the same data. An owner needs billing and compliance; a teacher needs the register and the day's activities; a parent needs to know their child arrived and what they did. Same records, three products. Then there is a fourth surface that is not a product at all — a tablet bolted by the front door, used by a queue of different parents every morning, with no one logged in and school wifi that drops.
Tenancy is resolved from the subdomain and carried on every request, so a user never selects which school they are looking at and cannot be in the wrong one by accident. The alternative — a dropdown and an id in application state — makes the tenant a thing the client decides, and the first bug you get is somebody's data appearing under somebody else's letterhead.
It shares the same routes, services and session plumbing rather than being built and deployed separately. A second app would have meant two release cycles and two copies of the attendance logic drifting apart. The cost is that the kiosk lives inside a build that also contains the admin panel, which is a boundary that then has to be defended deliberately rather than by architecture.
The device is unlocked once by the school, and each person at it identifies themselves separately — a parent by email and a four-digit PIN or a scanned code, a teacher from the roster. Asking a parent at a doorway to type a password would take longer than the drop-off itself; a device with no identity at all cannot tell you who signed the child in.
Ending a kiosk session pushes any pending attendance before wiping the session keys. Clearing first is the obvious order and quietly discards the check-in that was mid-flight — the exact event the whole surface exists to record.
Gave up
A separate, hardened kiosk application
Bought
One codebase, one release, and attendance logic that cannot drift between two implementations — at the price of a boundary that has to be enforced rather than assumed
Gave up
Passwords at the door
Bought
A four-digit PIN and a queue that moves at drop-off speed. Shorter secrets on a shared device are a real reduction in strength, accepted because the alternative is a system nobody uses.
Gave up
Letting the client pick its tenant
Bought
A school that follows from the address bar, so being in the wrong tenant requires being at the wrong URL rather than making the wrong selection
Live
app.whitepenguin.co
in production
Role surfaces
4
admin, staff, parent, kiosk
Tenancy
subdomain
one school per host
Ratios are given as raw counts rather than percentages. A percentage implies a precision that twenty attempts do not have.