← back to work case study · service design

The Human platform: scheduling, classrooms, records, and billing for four kinds of people.

Designed for my own tutoring practice, built from March 2026, live with families since mid-June.

Role Founder; service designer; sole builder-operator.
Timeline March 2026–present; live since June 2026.
Scope Service model, four role surfaces, AI-assisted lesson records, self-hosted stack.
Status Soft-launch, real families.

Classes ran on Whereby; parents were on three different chat apps.

Six disconnected apps, billing reconciled by hand, and records about minors on third-party clouds.

Human is the small tutoring practice I run, and it existed long before its platform did. It ran the way small practices usually do, on whatever was closest to hand. Classes happened over Whereby. Scheduling lived in Google Calendar, files in Google Drive. Parents, most of whom read and think in Mandarin, reached me on WeChat, WhatsApp, or iMessage, whichever their household already used. Billing was me at the end of the month, matching e-Transfers and WeChat Pay against a calendar by hand.

It mostly worked, the way loose things work. It also meant every family lived on a different app. A lesson could end and leave no record anywhere. A parent asking how their child was doing got an answer composed from memory, in English, in whatever thread happened to be open. Reconciling a payment meant scrolling back through whichever app it had arrived in. Nothing connected, and nothing was bilingual by design. And the records that did exist, records about minors, sat on third-party clouds chosen for convenience.

Underneath everything sat a harder constraint. I wanted AI in this service, because the clerical load on a solo teacher is exactly what a machine should carry. I was not willing to let a machine speak to a child unsupervised. None of the six apps was going to fix any of this, and per-seat SaaS priced every fix by the student. So in March 2026 I stopped patching and started designing the service the practice needed.

A parent and a teacher sign into the same address and land in different rooms.

One sign-on, four roles: the role a person holds decides their dashboard, calendar, notifications, and language, checked on every request.

The service model starts from who is asking. An admin runs the practice and wants to know what needs attention today. A teacher wants this afternoon’s classes and whatever is waiting on their sign-off. A student wants to know what to do next, ideally without an adult standing over the answer. A parent mostly wants two answers: is my kid okay, and what am I paying for.

One sign-on resolves all four. The role a person holds decides what gets assembled when they arrive: their dashboard, their calendar, their notifications, their language. A student never sees billing. A parent never sees another family. A teacher sees their own students and no one else’s. Those boundaries are checked on every request, underneath the interface, so they hold even when someone goes looking for the seams.

The family surfaces are also built to be read by everyone the service touches. They target WCAG 2.2 AA, and each account keeps its own way of reading: text scale, high contrast, reduced motion, a dyslexia-friendly typeface. The platform remembers those choices per person, on every device they sign in from.

admin
Admin dashboard: today's two classes, a needs-attention panel reading all clear, recent enrolments, and the full practice navigation down the side.
teacher
Teacher dashboard: today's scheduled sessions, each with a start-class button, and a link to subscribe to the class calendar.
student
Student dashboard: a greeting, the next class time, an open-classroom button, and to-do and in-progress panels; no billing anywhere.
parent
Parent dashboard: a greeting, the next class time, a your-children panel for their own child only, and recent classes.
Four rooms The same platform signed into four ways; every dashboard is scoped to its role, and everyone pictured here is fictional.

Follow one family from the welcome message to the day everything is erased.

Onboarding is eight steps that run as one; leaving is a single erasure that cascades through every stack, and it sits on the blueprint too.

Onboarding is eight steps that run as one. When a family joins, the platform creates their accounts, wires up a calendar feed, sets the rate and the session pack, seeds the recurring schedule, opens their file folder and workspace, and sends a welcome in both languages. The admin starts it; the sequence runs in order, the same way every time. I automated this for a plain reason: the admin here is also the teacher, and an evening spent copying names between systems is an evening not spent on someone’s lesson.

From there the rhythm is weekly. The schedule recurs on the same open calendar standard everything else already speaks, so lessons show up in whatever calendar app a household trusts. A reschedule is a request with an approval queue behind it; approve it and the calendar and the notifications sort themselves out. No renegotiating across three chat threads.

On class day the student lands in a lobby and knocks. The lesson starts when the teacher lets them in, and there is no other way into a live classroom.

Each lesson leaves a trail. The recording becomes a transcript on the practice’s own hardware, an AI drafts next steps from it, and once a teacher signs off (the next section is entirely about that gate), those steps land on the student’s own board. On day 28 of the cycle, the invoice assembles itself from the session records, bilingual like everything else a family sees.

And when a family leaves, the platform is built to forget them. One erasure request cascades through every stack that ever held their data, from lesson records to invoices. PIPEDA grants families that right; this service treats it as a step on the blueprint like any other. I have run the cascade live and checked what it left behind. Nothing.

a person acts the system carries it the teacher decides
onboardingeight steps, one run
schedulingthe weekly rhythm
live classlobby, knock, admit
lesson recordsa teacher signs off
billingday 28 of the cycle
leavingthe right to be forgotten
student
sets a password, has a look around
sees the week’s lessons
lands in the lobby and knocks
finds new steps on their board
·
·
parent
fills in the family’s details
asks to move a lesson
·
·
gets the invoice, pays it
asks the service to forget them
teacher
·
·
lets the student in and teaches
approves, edits, or throws out the draft
·
·
line of visibility
admin
checks the details, starts the eight steps
sets the recurring schedule, approves changes
·
·
checks the numbers, records the payment
runs the erasure, checks what is left
system
accounts, calendar, folders; a welcome in both languages
updates calendars and notices on its own
holds the lobby; records the lesson
turns the recording into a transcript and a draft
builds the invoice from the month’s lessons
the cascade clears every stack, invoices included

→ scroll the lifecycle sideways on a narrow screen

Lifecycle One family’s arc through the service, four lanes of people and one of systems, from the eight onboarding steps to the erasure cascade at the end; departure is drawn on the blueprint because it is part of the service.

Between the AI and the student, there is always a teacher.

A local model drafts the next steps; a teacher approves, edits, or rejects each one, and nothing reaches a family unread.

Every lesson ends with the same question: what should this student work on before next time? On this platform a machine answers first. The recording becomes a transcript, a local model reads it, and out come drafted action items. Finish the outline. Rework the two marked paragraphs. Bring the practice test on Thursday.

The student sees none of this. A draft is invisible on every family-facing surface; it exists in exactly one place, the teacher’s review queue. There the teacher approves it, edits it, or throws it out. Approval is the only door. When the teacher edits, the platform keeps the AI’s original wording beside the final version, so the gap between what the machine heard and what the teacher meant stays on the record. When the teacher rejects, the student never knows a draft existed.

Why so strict? Because the practice sells a teaching relationship: a person who knows this student and catches what a transcript flattens. The teacher stands behind every word the service puts in front of a child, and a machine suggestion sent unreviewed, however plausible, spends that trust. The AI makes the record cheap to produce. The teacher makes it true.

AI draftsa local model reads the transcript
teacher reviewsapprove, edit, or reject
if rejected, the student never sees it
student’s boardonly approved items land
The teacher's agenda-review queue: two pending action items, one per student, each tagged AI draft and waiting to be approved, edited, or rejected.
The gate Dashed strokes are the machine’s draft, solid strokes are the teacher’s decision; the review screen beside the diagram is where a draft becomes a lesson record or quietly stops existing.

Parents read this platform in the language they worry in.

Chinese sits beside English in the data model itself, written at the source, so every notice to a parent arrives in both scripts.

Most of the practice’s parents are more at home in Mandarin than English. Before the platform, everything official arrived in English anyway, and the nuance travelled by chat app, when it travelled at all.

The platform treats Mandarin as a first language, not a translation layer. Chinese fields sit beside the English ones in the data model itself, written together at the source. The parent and student surfaces have a full Traditional Chinese mirror, with a Simplified conversion generated from it automatically. When the platform has something to tell a parent, a reschedule, an invoice, a welcome, it says it in both scripts in the same breath. Staff surfaces stay in English, the language the practice operates in.

The difference is small and weekly. A schedule change reads the way the household speaks. An invoice explains itself without a translation app. Of the two answers a parent wants from this service, both now arrive in the language they would ask in.

parent · English
The parent overview on a phone, in English: a greeting, the next class time, reschedule and all-classes links, and the family's children.
parent · 繁體中文
The same parent overview on a phone, in Traditional Chinese, mirroring the English layout field for field.
Two scripts The same parent surface in English and Traditional Chinese; both versions are written into the record together, and a Simplified conversion is generated from the Traditional automatically.

The whole service runs on two machines I can point at.

About 14 self-hosted stacks on two machines for roughly $30 a month, with a child's voice never leaving the building.

Underneath the service sits a deliberately small build: ~14 self-hosted stacks, 30+ containers, two machines. One sign-on stands in front of everything a family touches. Each job runs as its own stack (identity, classrooms, records, files, billing, the AI pipeline), which keeps failures local and lets any piece be swapped without moving the rest. I leaned on that sooner than expected; more on it in the next section.

Self-hosting was a privacy decision before it was a cost decision. Recordings, transcripts, and everything the AI reads or writes stay on hardware in the building. A child’s voice never travels to a third-party API to become a lesson note.

The cost argument still holds, though. It all runs for about $30 a month. Per-seat tools would have attached a fee to every student, per product, forever; this attaches one small bill to the practice, whatever the roster does.

And it is operated by the same person who designed it. I patch it, back it up, and teach on it, which means any operational shortcut I take lands on my own students within days. Few incentives are cleaner than that.

a person acts the system carries it
one tunnel, one sign-on*.forhuman.ca

the NAS

identity
single sign-on auth.
classroom
role dashboards class. live classroom meet.
records
the student record internal site analytics analytics.
files
files & recordings cloud. reading library library. shared workspace work. nightly backups
billing
invoices & payments billing.

the GPU workstation

AI
records the lesson turns speech into text drafts the next steps reads documents & whiteboards
Two machines The ~14 stacks grouped by the job they do, identity through billing, with the AI pipeline kept on hardware in the building so a student’s voice never leaves it.

The build kept a written record of its own mistakes.

Audit-first: a June triage closed about 30 of 40 findings overnight, and a later adversarial audit's 78 were all fixed before families arrived.

A platform for other people’s children should not run on its author’s confidence. So the working method was audit-first. The system gets audited read-only; findings land in a docs folder; the docs get amended over time, so the first version of a finding stays visible under the fix. Both eras of every reversed decision are still on file.

And there were reversals. The video stack was replaced mid-build. A task tool was retired when the platform’s own boards covered the job. A contract-signature service came out entirely once a simpler local wizard made it redundant. All of it is in the record, because an audit trail that only ever says everything is fine is decoration.

Two audits shaped the launch. A June triage ranked 40 findings; about 30 closed overnight. Two of the 40 would have stopped a family mid-task, and both traced back to a single date-handling regression in the data layer. One root cause. It was fixed that night, and a guard now runs in CI so that class of mistake cannot land again. Three days later, an adversarial audit went after the platform on purpose and confirmed 78 findings, two of them critical; all 78 were remediated before families arrived. The same week, the backups got the only test that counts, a full restore, performed and verified.

the launch audits, in order
June triage 40 findings ranked, about 30 closed overnight
two customer-blocking failures both traced to a single date-handling regression
the fix patched that night, and a guard now runs in CI
adversarial audit, three days later 78 findings confirmed, 2 critical, all remediated
backup restore a full restore, performed and verified
One root cause The June triage in numbers: 40 ranked findings, about 30 closed overnight, and the two customer-blocking failures that traced to a single date-handling regression, now guarded in CI.

A few families, the full loop, no projections.

The whole loop runs in production. A handful of real families, and I am its heaviest user.

The platform soft-launched in mid-June 2026. A small number of families use it, and I am not going to dress that up. The claim this page makes is narrower and, I think, better: the whole loop runs in production. Classes get scheduled, taught in the live classroom, recorded into lesson notes a teacher approved, and billed, with no glue work happening in a chat thread at midnight.

I am also the service’s heaviest user. I hold the admin role and the teacher role, so every design decision gets tested in my own classes soon after it ships. It is the shortest feedback loop I have ever worked inside.

The next test is a second teacher. The roles, the gate, and the ownership rules were all designed for more people than currently use them. I will find out whether that design holds the day a colleague joins. Until then, no projected numbers.

The practice is called Human. It lives at forhuman.ca.

Class day A student’s route through a lesson, home to agenda to calendar to lobby, captured on the development stack with fictional people.