← 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.

Client Human, the bilingual tutoring practice I founded and run.
Sector Education, tutoring services
My Role Founder; service designer; sole builder-operator
Team Built and operated solo.
Duration March 2026–present; live since mid-June 2026
Methods Service blueprinting, role-based access design, self-hosted systems architecture, AI-assisted workflow with a human approval gate, adversarial security audit
Outputs A live self-hosted platform: four role surfaces, AI-drafted lesson records under teacher approval
Permissions My own practice, soft-launched to real families. Live at forhuman.ca.

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 pricing would only have made switching worse. 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 same address opens onto four different rooms, and the walls between them are load-bearing.

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.

A family's whole arc, from welcome message to the day everything is erased, fits on one blueprint.

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 update to match. No renegotiating across three chat threads.

On class day the student arrives 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, those steps appear on the student’s own board. On day 28 of the cycle, the platform assembles the invoice 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.

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 signs off on it, or it does not go 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.

The rule is that 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. 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 the AI kept on hardware in 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.

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, so any operational shortcut I take reaches my own students within days.

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.

The build kept a written record of its own mistakes.

Every finding stayed on file, and the one bug that mattered traced to a single root cause, now guarded in CI.

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. I replaced the video stack mid-build. I retired a task tool 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. Two findings would have stopped a family mid-task, both tracing 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 recur. Three days later, an adversarial audit went after the platform on purpose, and everything it found was fixed 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 fixed
backup restore a full restore, performed and verified
One root cause The two customer-blocking failures both traced to a single date-handling regression, now guarded in CI; the rest of the record is what audit-first catches before it reaches a family.

A few families, the full loop, no projections.

The whole loop runs in production, end to end, though the audience for it is still small enough to count on two hands.

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 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.

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.