I was halfway through the family taxes when my phone buzzed: “Your auto insurance renews tomorrow.”

I had a vague memory of that email arriving three weeks earlier. I’d meant to compare quotes. I’d put it on a list somewhere — the wrong list, in the wrong app, scrolled past three days ago. Now I had until 11:59 the next night to renegotiate, or auto-renew at the rate I’d quietly meant to challenge.

That moment isn’t unusual. It’s the texture of running a household. Insurance renewals, tire changes, vaccine schedules, expiring rewards, the mortgage rate that resets in fourteen months, the boat motor that needs an inspection before launch. Each item is small on its own. The work is remembering all of them, at the right cadence, forever — and it compounds, because you also have to remember what you put on which list, in which app.

I’ve written software for a long time. I’ve tried calendars, Todoist, Notion, spreadsheets, Apple Notes, Reminders, even a full Trello board. Each solves one slice. None solve the actual problem:

The cognitive load of running a household is not a productivity problem. It’s a knowledge problem.

Productivity tools assume you’ve already done the hard part — noticed the obligation, understood what it was, decided it mattered, and filed it in the right place. That’s precisely the work I want to disappear. The renewal that fires tomorrow doesn’t need a checkbox. It needs a system that read the original email three weeks ago, knew what kind of commitment it represented, knew that I like to compare quotes annually, and said so while there was still a week left to act.

That takes three things a calendar doesn’t have:

1. A way to ingest the messy artifacts real life produces — a scanned bill, a photo of the boiler nameplate, a mortgage statement, the email from the dealership.
2. A knowledge graph of the relationships: this car belongs to this person, who lives at this address, heated by this boiler, serviced by this company, under contract until this date.
3. A predictive layer that knows enough about how the world works to say: given all that, here’s what happens next, and when.

Why this product, for this experiment

I didn’t start with the product. I started with an experiment about how software gets built — what AI agents can genuinely carry, and where quality comes from once a machine writes the code.

That experiment needed something real to be judged against. A toy passes every test you write for it, because you wrote them for the toy. I needed a system with real data, real consequences for being wrong, and a user who would notice the same day if it got worse.

A household turns out to be an unusually demanding customer. The data is genuinely messy and arrives in no order. The rules are regional and change. The failure modes are specific and unforgiving — a renewal missed by one day is missed. And the person affected by a bad prediction lives with the person who shipped it.

So the bar has been the same since the first sprint: it has to save me real time on real life-admin before it is offered to anyone else. Not demo well. Save time, on my own paperwork, measurably.

How it’s built

• Solo, in weekly sprints, dogfooded from day one. My family’s data, my bills, my obligations.
• AI-native, but not AI-only. Ingestion is a vision-capable model, not a pile of regexes. Prediction is deterministic rules plus model-drafted proposals I confirm before they fire. The knowledge graph is plain Postgres — it’s fine, and it lets me move fast on the parts that matter.
• Privacy as a hard constraint. This is family data. Every household isolated at the database level, encryption at rest, and an architecture that keeps the door open to a stronger model later. The current posture is described honestly in the app rather than marketed.
• Correct for somewhere specific. Cadence rules need to be right for one place, not vaguely right for fifty. That was Quebec first; it’s grown outward from there.

I’m writing this publicly because I’ve started enough projects where an honest sprint diary would have been more useful than the eventual launch post. So you get the actual sequence of decisions here, including the wrong ones — every sprint, including the ones where the interesting part was what broke.

That’s the deal: I’ll show my work.