A tutor we work with runs their teaching week out of Google Calendar. Every class is already there, sitting among the dentist appointments and the school run. Every student has their own hourly rate. At the end of each month, the bills had to come out of those two facts.
In practice that meant an evening. Scroll the month, find the classes, add up the hours per student, look up each rate, do the multiplication, remember that one Tuesday was cancelled and the Thursday ran long, then type it all out. Careful, boring, error-prone work, every month, forever — and time that would rather have gone into teaching.
Nothing here needed inventing.
The striking thing about the job is that no new information was involved. The calendar already knew which classes happened and how long they ran. A rate sheet already knew what each student pays. Everything between those two inputs and a finished bill was transcription and arithmetic.
That is the shape worth automating: not a hard problem, a tedious one. Hard problems need judgement. Tedious ones need doing precisely, every time — and a computer is not bored by the last name on the list.
What happens now.
On the first of the month, early in the morning, a small program wakes up. It reads last month's calendar, picks out the classes, groups them by student, applies each rate, and emails a plain-text bill. Then it sleeps for a month.
The rates live in a Google Sheet the tutor owns and edits. A new student is a new row; a change of rate is a changed cell. Neither involves us. And everything the program touches, it touches read-only — it can read the calendar and the sheet, and it cannot alter either one.
The interesting part was the mess.
Real calendars are not tidy. A class gets entered with a typo in the title. A cancelled week is annotated rather than deleted. Someone makes an all-day entry with no hours in it. An end time is left wrong, so a one-hour class looks like it ran for nine. Two students have names where one contains the other.
A naive script bills all of that incorrectly, and quietly. Ours refuses to guess. Anything it cannot bill confidently goes into a "needs attention" block at the top of the bill — the entry, the date, and the reason — and the rest of the bill still goes out. Never silently drop billable time, and never invent a number. That single rule drove most of the design.
Who watches it.
This is the part we think matters most, and it is not code. The tutor gets the bill. We get the operations: every run tells us whether it succeeded, failed, or found something it could not classify. We monitor that for the first six months at no charge, as part of the engagement.
Something that runs once a month is exactly the kind of thing that fails silently. Without someone watching the machinery, the first symptom is a bill that never arrives — and by then it has been broken for weeks.
What it took.
Two days. Around twelve hundred lines of Python, and a hundred and ten tests aimed at the cases that actually break it: the typo, the ambiguous name, the nine-hour class. The tests are what make it trustworthy, because nobody is going to be watching on the first of the month.
Two days is the whole point. An evening a month is a real cost, and it has never been worth a traditional software project to remove it. That arithmetic has changed. The work worth automating now is the small, dull, specific kind — the kind nobody would ever have commissioned software for.