Why I built a school-assignment app for my daughter
It is 9:40pm. My daughter is asleep. I am logged into her school's portal, clicking through twelve subject tabs one at a time, because somewhere in there is the answer to a single question: does she need to bring anything tomorrow.
The portal is a school ERP. It has everything. Attendance, fee receipts, a photo gallery, a circular about the upcoming sports day, and, buried under all of it, the actual classwork. Each subject is its own tab. Each tab is a list. Each list item opens a detail page written by the teacher after the school day, in the past tense, describing what happened in class. Most of it is a recap. Occasionally, in the third paragraph, there is a sentence that matters: "spelling test on Unit 5 next Tuesday." That sentence is the reason I am awake.
This is a series about building a small piece of software to answer that one question, for an audience of exactly one parent and one child. Over the next several parts I will get into the mechanics: scraping a portal that has no API (Part 2), using a language model to separate genuine future tasks from the daily recap noise (Part 3), generating warm parent-facing summaries without paying the model twice for the same thing (Part 4), a small question-answering agent that reaches back through the year (Part 5), and how I keep an eye on what all of this costs (Part 6). This first part is about why it was worth building at all, which is the part I had to be honest with myself about before writing a line of code.
The portal is not the problem. The shape of the answer is.
The easy story is "the school's software is bad, so I built better software." That is not quite true, and it is worth being precise about why, because the precision is the whole design.
The portal is fine at being a system of record. It stores everything, it is the source of truth, and a teacher can post to it in thirty seconds. The problem is that a system of record and a parent's evening have completely different shapes. The portal is organized by subject, because that is how a school is organized. My evening is organized by time: what is due tomorrow, what needs preparing this week, what test is coming that we should start revising for tonight. Those two shapes do not line up, and the work of lining them up by hand, every night, across twelve tabs, is exactly the work the software needed to remove.
Put that way, the project stops being "rebuild the portal" and becomes something much smaller and much more achievable: a translation layer. Read what the portal already has, and re-shape it into the four or five things a parent actually acts on. I am not competing with the school's software. I am reading its output and answering a different question with it.
One job, and the discipline of an audience of one
The most freeing constraint here was the size of the audience. One family. One child, in Grade 2. I was never going to onboard a second school, support a second portal layout, or handle a district's worth of edge cases. That sounds like a limitation. It is the opposite: it is permission to hard-code.
When you build for everyone, every assumption has to become a setting. When you build for one kid, her twelve subjects can be a config file I edit by hand. Her school's quirky portal layout can be parsed with a regex I tune to exactly that layout, and if the layout changes I will notice the next morning and fix it that night. Her grade and her teachers can sit in a prompt as plain context. None of that would survive contact with a real product. All of it let me ship something useful in evenings instead of quarters.
There is a real cost to this, and I want to name it rather than pretend the approach is free. Everything is brittle on purpose. The scraper is coupled to one portal's HTML. The prompts know one child's grade. The day the school migrates to a new ERP, a large part of this stops working and I rewrite it. I made that trade deliberately, because the alternative, a flexible system that handles schools I will never have, is a much larger project that I would never have finished, to solve a problem I do not have.
A tool for one person can make assumptions a product would have to turn into settings. That is not a smaller version of the product. It is a different, easier problem.
Why software, and not just a habit
The fair challenge to all of this: I could just read the portal carefully once a week and write the important bits on the fridge. People raised children long before school ERPs. Why build anything.
Two reasons, and only the second one held up.
The first reason I told myself was time, and it was mostly a lie. The half hour a week I spend clicking tabs is not really the problem, and if I am honest, building this cost far more than that half hour will ever return. Automating a small chore to spend many more hours building the automation is a familiar kind of self-deception, and I should admit it is partly just that.
The second reason is the real one: consistency under fatigue. The failure mode was never that the task is long. It is that at 9:40pm, tired, I skim, and I miss the one sentence in the third paragraph. The fridge note only works on the nights I am sharp enough to write it. A system that reads every assignment the same way, every night, whether or not I am paying attention, is not saving me thirty minutes. It is removing a class of quiet failures, the kind you only discover when your kid is the one who showed up without the art supplies. That is worth building for, and it is the thread that runs through the rest of this series: not "faster," but "doesn't depend on me being at my best."
What this series is
Everything from here is concrete. The next part is the least glamorous and the one I am fondest of: getting the data out of a portal that was never meant to be read by anything except a browser, and why my first instinct, a real headless browser, was the wrong one. After that, the part that makes the whole thing work, which is teaching a model to ignore almost everything a teacher writes and surface only the handful of sentences a parent has to act on.
The takeaway I would offer before any of the code: the smallest useful version of "an app for my family" is not a smaller product. It is a translation layer over software that already exists, built for a single reader, allowed to be brittle, and aimed at the one failure that actually matters. Define that failure first. The rest is just plumbing, and the plumbing is the fun part.