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 school portal assignment tracker 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, the part worth getting clear on before writing a line of code.
TL;DR
School portals are organized by subject, but a parent's evening is organized by urgency: what is due tomorrow, what to bring, what test is coming. I built a small translation layer that scrapes my daughter's school ERP, uses a language model to pull out the handful of actionable sentences buried in teacher recaps, and reshapes them into the four or five things a parent actually acts on. The project is deliberately brittle and built for an audience of one, which is what made it possible to ship. It does not save time so much as it removes a class of quiet failures that only show up when you are too tired to read carefully.
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 for one family: the discipline behind a personal assignment tracker
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 trap, and this was partly 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.
Before any of the code, this is the point: the smallest useful version of "an app for my family" 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.
FAQ
How do I scrape a school portal that has no API?
The author covers this in Part 2 of the series, noting that a headless browser was the wrong first instinct. The approach is to read the portal's existing HTML and parse it with a regex tuned to that specific layout, accepting that the scraper will be tightly coupled to one portal's structure.
How do I use an LLM to extract homework and test reminders from teacher notes?
The author prompts the model to ignore the daily recap and surface only sentences a parent has to act on, such as upcoming tests or items to bring. This is covered in Part 3 of the series, which focuses on separating genuine future tasks from recap noise.
Is it worth building a custom school assignment tracker instead of just checking the portal?
The author argues the real value is not saving time but removing failures caused by fatigue. Skimming a portal at 9:40pm means occasionally missing a critical sentence; a system that reads every assignment consistently every night eliminates that class of quiet miss.
Why build a personal tool that is brittle instead of something more flexible?
Building for one child lets you hard-code assumptions that a product would have to turn into settings, which makes the project small enough to actually finish. The author treats brittleness as a deliberate trade-off: when the school changes its ERP, a rewrite is acceptable because the alternative is a much larger project that would never have shipped.
What is a translation layer app and how is it different from rebuilding a school portal?
A translation layer reads the output of software that already exists and reshapes it to answer a different question. Instead of replacing the school ERP, the author's app reads its data and converts the subject-organized structure into a time-organized list of things a parent needs to act on.