Home App: From a Shopping List to a Private Home System

It started with household shopping

Home App started from a banal problem: a shared shopping list. Not from architecture, not from a stack — from the fact that someone added milk, someone else was already at the store, and the information arrived one floor too late. A classic enterprise-grade problem: a distributed system made of a few people and one fridge couldn't reach consensus.

Then came tasks, a calendar, reminders, notebooks, a Home Assistant integration, and a local AI agent. At some point it stopped being a side project. It became a small production system — except that instead of anonymous users it has household members, who report a failure immediately, usually at the dinner table.

Why a family tests better than localhost

On localhost everything works. Except localhost doesn't do the shopping, doesn't forget about training, and doesn't ask for the third time whether the calendar has refreshed yet. It's the real, non-technical users who find bugs where nobody looked — and they do it faster than any test suite.

There's no formal SLA here. There's something more effective: the question from the kitchen asking why the reminder never came. The tolerance window is small — a scheduled reminder either fires on time, or someone asks, and not just once.

Decision 1: shared first, private only when needed

In a typical app everything is "yours," and whatever someone else should see has to be shared manually. At home that's tiring — the shopping list and calendar are meant to be shared from the start, without clicking "share." So in Home App the default is the household: shared things are shared by design, and household members are simply whoever happens to be logged in.

But not everything is for everyone. Tasks and notes have a visibility level — shared, parents-only, or private — so gifts or grown-up matters don't end up in front of the kids. This isn't a fancy data model, it's domestic ergonomics: you don't have to manually share what's shared anyway, and what's private stays private. Underneath, one rule enforces it: every query starts from the family boundary, and visibility decides the rest.

-- The boundary is the family (profile_id); visibility decides who sees what
SELECT * FROM tasks
WHERE profile_id = $1
  AND (
    visibility = 'shared'
    OR (visibility = 'parents_only' AND $2)          -- $2 = parent role
    OR (visibility = 'private' AND created_by = $3)  -- $3 = user id
  );

Decision 2: notifications are a household SLA

Notifications quickly stopped being a plain "send a message." It's a separate system: per-user routing (ntfy or Telegram), severity thresholds, and quiet hours. A high-severity alert goes through immediately; the rest, if it lands during quiet hours, goes into a queue and waits — an n8n workflow checks it every 15 minutes and releases the messages once quiet hours end. It sounds like overkill, until you hear at breakfast that a reminder "was an hour late because it sat in a queue."

# The notification flow:
# Alertmanager → n8n Dispatcher → GET /api/notifications/targets
#   → per-user: ntfy | Telegram
#   → quiet hours: INSERT INTO notification_queue
#   → n8n every 15m → POST /api/notifications/process-queue

Decision 3: AI as a remote control for the home, not a gadget

The AI agent in Home App isn't a chatbot for small talk. It has persistent memory and a set of tools: it reads alerts, searches and creates notes, checks the weather, and — most interestingly — controls the home through Home Assistant. So it can actually do something, not just answer: send a robot to clean the living room, or check the dishwasher's state. The same home where a barcode scan tells you which bin the packaging goes into.

A good example of the line between architecture and interface: a question from a watch — "how long until the cake is done?" If the oven, or even just a timer, is an entity in Home Assistant, the agent reads the remaining time and answers by voice. This isn't a new architecture — it's the same agent and the same tools, just asked from the wrist.

The interesting part is that new scenarios don't require rebuilding the app. If the oven timer, a plant sensor, or the dishwasher are entities in Home Assistant, the agent reads them with the same tool. The interface changes — a watch, a kitchen tablet, voice — but the foundation doesn't.

The core runs locally: an Ollama model runs on the home server, so prompts, notes, and context never leave the building. The real constraint is hardware — without a GPU, simple replies are acceptable, but agent requests that use tools can take several minutes. That is an honest trade-off for privacy and offline operation, not a promise of cloud API speed.

How it works together

In practice, Home App is a layer between the household, the database, notifications, and Home Assistant devices.

Under the hood: a boring stack

Deliberately boring: React + TypeScript on the frontend, Express + TypeScript on the backend, PostgreSQL (no ORM, raw parameterized queries), Socket.io for real-time events. No Next.js on the backend, no GraphQL, no Prisma. The reason is mundane: at 2am, when a reminder didn't fire, you don't want to discover a framework's philosophy — you want to read what happened and fix it.

For a close-up of what that boring stack looks like at the level of a single feature, see the notebook with camera, voice and OCR.

What this project taught me

It's still a home app. It doesn't serve a million users, has no SRE team and no roadmap in Jira. But it works for people who actually use it — and that was enough for an ordinary shopping list to start requiring permissions, roles, queues, real-time, notifications, and a local agent.

Because Home App isn't a shopping app, a calendar, or an AI app. It's a layer that joins household members, data, and devices into one private home system — without more logins, subscriptions, and data sent who knows where.

For a project meant to solve the milk-at-the-store problem, this went suspiciously far.