Home App: od listy zakupów do prywatnego systemu domowego

Zaczęło się od problemów z zakupami domowymi

Home App zaczęła się od banalnego problemu: wspólnej listy zakupów. Nie od architektury, nie od stacku — od tego, że ktoś dopisywał mleko, ktoś inny był już w sklepie, a informacja docierała na miejsce o jedno piętro za późno. Klasyczny problem klasy enterprise: system rozproszony złożony z kilku osób i jednej lodówki nie potrafił osiągnąć konsensusu.

Potem doszły zadania, kalendarz, przypomnienia, notatniki, integracja z Home Assistant i lokalny agent AI. W którymś momencie to przestał być projekt poboczny. Stał się małym systemem produkcyjnym — z tą różnicą, że zamiast anonimowych użytkowników ma domowników, którzy zgłaszają awarię od razu, zwykle przy stole.

Dlaczego rodzina testuje lepiej niż localhost

Na localhost wszystko działa. Tyle że localhost nie robi zakupów, nie zapomina o treningu i nie pyta po raz trzeci, czy kalendarz już się odświeżył. Dopiero realni, nietechniczni użytkownicy znajdują błędy tam, gdzie nikt ich nie szukał — i robią to szybciej niż jakikolwiek zestaw testów.

Nie ma tu formalnego SLA. Jest coś skuteczniejszego: pytanie z kuchni, dlaczego przypomnienie nie przyszło. Margines tolerancji jest mały — zaplanowane przypomnienie albo zadziała o czasie, albo ktoś dopyta, i to nie raz.

Decyzja 1: najpierw wspólne, prywatne dopiero gdy trzeba

W zwykłej aplikacji wszystko jest „twoje", a tym, co ma zobaczyć ktoś inny, trzeba się podzielić ręcznie. W domu to męczące — lista zakupów i kalendarz mają być wspólne od razu, bez klikania „udostępnij". Dlatego w Home App domyślny jest dom: wspólne rzeczy są wspólne z założenia, a domownicy to po prostu ci, którzy akurat są zalogowani.

Ale nie wszystko ma widzieć każdy. Zadania i notatki mają poziom widoczności — wspólne, tylko dla rodziców albo prywatne — więc prezenty czy dorosłe sprawy nie trafiają przed oczy dzieci. To nie fikuśny model danych, tylko domowa ergonomia: nie musisz udostępniać ręcznie tego, co i tak wspólne, a co prywatne, zostaje prywatne. Pod spodem pilnuje tego jedna zasada: każde zapytanie zaczyna się od granicy rodziny, a widoczność rozstrzyga resztę.

-- Granica to rodzina (profile_id); widoczność rozstrzyga, kto co widzi
SELECT * FROM tasks
WHERE profile_id = $1
  AND (
    visibility = 'shared'
    OR (visibility = 'parents_only' AND $2)          -- $2 = rola rodzica
    OR (visibility = 'private' AND created_by = $3)  -- $3 = id użytkownika
  );

Decyzja 2: powiadomienia to domowe SLA

Powiadomienia szybko przestały być zwykłym „wyślij wiadomość". To osobny system: trasy dla każdego użytkownika (ntfy albo Telegram), progi ważności i godziny ciszy. Alert o wysokiej ważności przechodzi od razu; reszta, jeśli wpadnie w ciszę nocną, ląduje w kolejce i czeka — workflow w n8n sprawdza ją co 15 minut i wypuszcza wiadomości po zakończeniu godzin ciszy. Brzmi jak nadmiar, dopóki nie usłyszysz przy śniadaniu, że przypomnienie „spóźniło się o godzinę, bo siedziało w kolejce".

# Przepływ powiadomienia:
# Alertmanager → n8n Dispatcher → GET /api/notifications/targets
#   → użytkownik: ntfy | Telegram
#   → godziny ciszy: INSERT INTO notification_queue
#   → n8n co 15 min → POST /api/notifications/process-queue

Decyzja 3: AI jako pilot do domu, nie gadżet

Agent AI w Home App nie jest czatem do pogawędek. Ma trwałą pamięć i zestaw narzędzi: czyta alerty, przeszukuje i tworzy notatki, sprawdza pogodę i — co najciekawsze — steruje domem przez Home Assistant. Potrafi więc coś zrobić, nie tylko odpowiedzieć: wysłać robota, żeby posprzątał salon, albo podejrzeć stan zmywarki. Ten sam dom, w którym skan kodu kreskowego podpowiada, do którego kosza trafia opakowanie.

Dobry przykład granicy między architekturą a interfejsem: pytanie z zegarka „ile zostało do końca ciasta?". Jeśli piekarnik albo choćby timer jest encją w Home Assistant, agent odczyta pozostały czas i odpowie głosowo. To nie jest nowa architektura — to ten sam agent i te same narzędzia, tylko zadane z nadgarstka.

Najciekawsze jest to, że nowe scenariusze nie wymagają przebudowy aplikacji. Jeśli timer piekarnika, czujnik rośliny albo zmywarka są encjami w Home Assistant, agent odczyta je tym samym narzędziem. Zmienia się interfejs — zegarek, tablet w kuchni, głos — ale nie fundament.

Rdzeń działa lokalnie: model Ollama chodzi na serwerze w domu, więc prompty, notatki i kontekst nie wychodzą na zewnątrz. Jedynym realnym ograniczeniem jest sprzęt — bez GPU proste odpowiedzi są akceptowalne, ale zapytania agentowe z użyciem narzędzi potrafią trwać kilka minut. To uczciwy kompromis za prywatność i pracę offline, nie obietnica szybkości chmurowego API.

Jak to działa razem

W praktyce Home App jest warstwą między domownikami, bazą danych, powiadomieniami i urządzeniami z Home Assistant.

Pod spodem: nudny stack

Świadomie nudny: React + TypeScript na froncie, Express + TypeScript na backendzie, PostgreSQL (bez ORM, surowe parametryzowane zapytania), Socket.io do zdarzeń w czasie rzeczywistym. Żadnego Next.js na backendzie, GraphQL ani Prismy. Powód jest prozaiczny: o drugiej w nocy, gdy przypomnienie nie zadziałało, nie chcesz odkrywać filozofii frameworka — chcesz przeczytać, co się stało, i to naprawić.

Jak taki nudny stack wygląda od kuchni na poziomie jednej funkcji, pokazałem na przykładzie notatnika z aparatem, głosem i OCR.

Czego nauczył mnie ten projekt

To nadal jest domowa aplikacja. Nie obsługuje miliona użytkowników, nie ma zespołu SRE ani roadmapy w Jirze. Ale działa dla ludzi, którzy naprawdę z niej korzystają — a to wystarczyło, żeby zwykła lista zakupów zaczęła wymagać uprawnień, ról, kolejek, czasu rzeczywistego, powiadomień i lokalnego agenta.

Bo Home App nie jest aplikacją do zakupów, kalendarza ani AI. To warstwa, która łączy domowników, dane i urządzenia w jeden prywatny system domowy — bez kolejnych loginów, abonamentów i danych wysyłanych nie wiadomo gdzie.

Jak na projekt, który miał rozwiązać problem mleka w sklepie, zaszło to podejrzanie daleko.