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.
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.
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.
→ scroll the lifecycle sideways on a narrow screen
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.
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.
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.
the NAS
the GPU workstation
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.
| 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 |
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.