Home App: Von der Einkaufsliste zum privaten Heimsystem
Home App begann als gemeinsame Einkaufsliste und wuchs zu einem privaten Heimsystem: Aufgaben, Kalender, Benachrichtigungen, Notizen, Home Assistant und ein lokaler KI-Agent. Der beste Praxistest war am Ende die Familie selbst.

Schwerpunkt
App-Entwicklung
Niveau
Einführung
Stack
Es begann mit dem Einkaufen im Haushalt
Home App begann mit einem banalen Problem: einer gemeinsamen Einkaufsliste. Nicht mit der Architektur, nicht mit dem Stack — sondern damit, dass jemand Milch hinzufügte, jemand anderes bereits im Laden war und die Information eine Etage zu spät ankam. Ein klassisches Enterprise-Problem: Ein verteiltes System aus ein paar Personen und einem Kühlschrank schaffte es nicht, einen Konsens zu erreichen.
Dann kamen Aufgaben, ein Kalender, Erinnerungen, Notizbücher, eine -Integration und ein lokaler KI-Agent. Irgendwann war es kein Nebenprojekt mehr. Es wurde ein kleines Produktionssystem — mit dem Unterschied, dass es statt anonymer Nutzer Familienmitglieder hat, die einen Ausfall sofort melden, meist beim Essen.
In Version v2.12 hat Home App: Mehrbenutzer-Authentifizierung mit Rollen, Aufgabenverwaltung, einen Familienkalender mit Erinnerungen, persönliche Notizbücher mit Volltext- und semantischer Suche, Home-Assistant-Widgets, einen KI-Chat auf Basis eines lokalen LLM sowie ein Benachrichtigungssystem, das Nachrichten pro Nutzer an ntfy oder Telegram leitet.
Warum eine Familie besser testet als localhost
Auf localhost funktioniert alles. Nur macht localhost keine Einkäufe, vergisst kein Training und fragt nicht zum dritten Mal, ob sich der Kalender schon aktualisiert hat. Erst echte, nicht-technische Nutzer finden Fehler dort, wo niemand gesucht hat — und das schneller als jede Testsuite.
Es gibt hier kein formales . Es gibt etwas Wirksameres: die Frage aus der Küche, warum die Erinnerung nicht gekommen ist. Das Toleranzfenster ist klein — eine geplante Erinnerung wird entweder pünktlich ausgelöst, oder jemand fragt nach, und das nicht nur einmal.
Entscheidung 1: zuerst gemeinsam, privat erst wenn nötig
In einer gewöhnlichen App ist alles „deins", und was jemand anderes sehen soll, muss man manuell teilen. Zu Hause ist das mühsam — Einkaufsliste und Kalender sollen von Anfang an gemeinsam sein, ohne auf „teilen" zu klicken. Deshalb ist in Home App der Haushalt der Standard: Gemeinsames ist von Haus aus gemeinsam, und Familienmitglieder sind einfach die, die gerade angemeldet sind.
Aber nicht alles soll jeder sehen. Aufgaben und Notizen haben eine Sichtbarkeitsstufe — gemeinsam, nur für Eltern oder privat — damit Geschenke oder Erwachsenenangelegenheiten nicht vor den Augen der Kinder landen. Das ist kein ausgefallenes Datenmodell, sondern häusliche Ergonomie: Man muss nicht manuell teilen, was ohnehin gemeinsam ist, und was privat ist, bleibt privat. Darunter sorgt eine Regel dafür: Jede Abfrage beginnt an der Familiengrenze, und die Sichtbarkeit entscheidet den Rest.
-- Die Grenze ist die Familie (profile_id); die Sichtbarkeit entscheidet, wer was sieht
SELECT * FROM tasks
WHERE profile_id = $1
AND (
visibility = 'shared'
OR (visibility = 'parents_only' AND $2) -- $2 = Elternrolle
OR (visibility = 'private' AND created_by = $3) -- $3 = Benutzer-ID
);
Entscheidung 2: Benachrichtigungen sind ein häusliches SLA
Benachrichtigungen waren schnell kein einfaches „sende eine Nachricht" mehr. Es ist ein eigenes System: Routing pro Nutzer (ntfy oder Telegram), Schweregrad-Schwellen und Ruhezeiten. Eine Meldung mit hohem Schweregrad geht sofort durch; der Rest landet, wenn er in die Nachtruhe fällt, in einer Warteschlange und wartet — ein n8n-Workflow prüft sie alle 15 Minuten und gibt die Nachrichten nach Ende der Ruhezeiten frei. Klingt übertrieben, bis man beim Frühstück hört, dass eine Erinnerung „eine Stunde zu spät kam, weil sie in der Warteschlange saß".
# Der Benachrichtigungsfluss:
# Alertmanager → n8n Dispatcher → GET /api/notifications/targets
# → pro Nutzer: ntfy | Telegram
# → Ruhezeiten: INSERT INTO notification_queue
# → n8n alle 15 Min → POST /api/notifications/process-queue
Entscheidung 3: KI als Fernbedienung fürs Haus, kein Gadget
Der KI-Agent in Home App ist kein Chat zum Plaudern. Er hat ein dauerhaftes Gedächtnis und einen Satz Werkzeuge: Er liest Meldungen, durchsucht und erstellt Notizen, prüft das Wetter und — am interessantesten — steuert das Haus über Home Assistant. Er kann also etwas tun, nicht nur antworten: einen Roboter losschicken, um das Wohnzimmer zu putzen, oder den Zustand der Spülmaschine prüfen. Dasselbe Haus, in dem ein Barcode-Scan verrät, in welche Tonne die Verpackung gehört.
Ein gutes Beispiel für die Grenze zwischen Architektur und Schnittstelle: die Frage von der Uhr — „wie lange noch, bis der Kuchen fertig ist?". Wenn der Ofen oder auch nur ein Timer eine Entität in Home Assistant ist, liest der Agent die verbleibende Zeit und antwortet per Sprache. Das ist keine neue Architektur — es ist derselbe Agent und dieselben Werkzeuge, nur vom Handgelenk aus gefragt.

Das Interessanteste ist, dass neue Szenarien keinen Umbau der App erfordern. Wenn der Ofentimer, ein Pflanzensensor oder die Spülmaschine Entitäten in Home Assistant sind, liest der Agent sie mit demselben Werkzeug. Die Schnittstelle ändert sich — eine Uhr, ein Tablet in der Küche, die Stimme — aber das Fundament nicht.
Der Kern läuft lokal: Ein -Modell läuft auf dem Server zu Hause, sodass Prompts, Notizen und Kontext nicht nach außen gelangen. Die echte Einschränkung ist die Hardware — ohne sind einfache Antworten akzeptabel, aber Agenten-Anfragen mit Werkzeugen können mehrere Minuten dauern. Das ist ein ehrlicher Kompromiss für Privatsphäre und Offline-Betrieb, kein Versprechen der Geschwindigkeit einer .
Wie es zusammen funktioniert
In der Praxis ist Home App eine Schicht zwischen den Familienmitgliedern, der Datenbank, den Benachrichtigungen und den Home-Assistant-Geräten.
Darunter: ein langweiliger Stack
Bewusst langweilig: + im Frontend, + TypeScript im Backend, (kein , rohe parametrisierte Abfragen), für Echtzeit-Ereignisse. Kein im Backend, kein , kein . Der Grund ist banal: Um zwei Uhr nachts, wenn eine Erinnerung nicht funktioniert hat, will man nicht die Philosophie eines Frameworks ergründen — man will lesen, was passiert ist, und es beheben.
Wie dieser langweilige Stack auf der Ebene einer einzelnen Funktion aussieht, zeige ich am Beispiel des Notizbuchs mit Kamera, Sprache und OCR.
Was mich dieses Projekt gelehrt hat
Es ist immer noch eine Haus-App. Sie bedient keine Million Nutzer, hat kein -Team und keine Roadmap in Jira. Aber sie funktioniert für Menschen, die sie wirklich nutzen — und das reichte, damit eine gewöhnliche Einkaufsliste anfing, Berechtigungen, Rollen, Warteschlangen, Echtzeit, Benachrichtigungen und einen lokalen Agenten zu erfordern.
Denn Home App ist keine Einkaufs-, Kalender- oder KI-App. Sie ist eine Schicht, die Familienmitglieder, Daten und Geräte zu einem privaten Heimsystem verbindet — ohne weitere Logins, Abonnements und Daten, die irgendwohin gesendet werden.
Für ein Projekt, das das Milch-im-Laden-Problem lösen sollte, ging das verdächtig weit.
Häufige Fragen
Ist das ein fertiges Produkt, das ich kaufen kann?
Nein. Es ist eine private App auf meinem Heimserver — die Fallstudie zeigt die Entscheidungen und die Architektur, kein Produkt zum Verkauf.
Warum nicht einfach fertige Apps (Todoist, Google Kalender)?
Ich wollte, dass die Familiendaten zu Hause bleiben — ohne Abos und ohne sie an Firmen zu senden — und an einem echten, täglich genutzten System lernen.
Welche Technologien treiben die App an?
React und TypeScript im Frontend, Express und PostgreSQL im Backend, Socket.io für Echtzeit, dazu lokale KI (Ollama) und Home Assistant.