Tech-USP: Realtime ist Default, nicht Add-on. Server-Sent Events (SSE) statt WebSocket-Setup. Cross-Aggregat-Updates über Multi-Stream-Projektionen — und Schema-Änderungen gehen in Sekunden live, ohne Re-Deploy.
Sicht des Käufers: Live-Updates wie bei Statuspages, Chats oder Dashboards funktionieren ohne externes Pusher/Ably-Abo. Im Designer um 14:32 ein Feld geändert — eure User sehen das neue Feld um 14:32:03. Kein Build, kein Deploy, kein „warten aufs nächste Release”.
Der große Differentiator: Schema-Änderungen ohne Re-Deploy
Die meisten Internal-Tools-Plattformen haben einen Edit-dann-Sync-Zyklus. Retool: im Editor bearbeiten, „Save”, User bekommen das neue Dashboard beim nächsten Reload. Supabase: Tabelle ändern, Types regenerieren, App redeployen. Lovable / v0: Prompt → ganzes Projekt regenerieren → deployen → auf neuen Build warten.
Kumiko überspringt diese Schleife. Der Designer (oder KI-Builder) schreibt eure Schema-Änderung in die Datenbank der laufenden App. Die App liest ihr eigenes Schema und broadcastet die Änderung über SSE. Verbundene User sehen das neue Feld, die neue Ansicht, die neue Rollenregel — in Sekunden, während sie noch auf derselben Seite sind.
| Was passiert | Zeit bis live |
|---|---|
| Feld zu einem Formular hinzufügen | Sekunden, kein Reload nötig |
| Neue Ansicht hinzufügen (z.B. „Tickets nach Abteilung”) | Sekunden, kein Reload nötig |
| Berechtigungsregel ändern | Sekunden, gilt beim nächsten Request |
| Komplett neue Entität hinzufügen (z.B. „Lieferanten”) | Sekunden, Schema migriert inline, User sehen es bei nächster Navigation |
Warum das für Käufer wichtig ist: „Wir haben ein Feld geändert, die App brauchte einen Re-Deploy, der Deploy ist gescheitert, das halbe Lager war eine Stunde offline” — das ist das Failure-Pattern, das ihr uns abkauft. Schema-Änderungen sind Daten, kein Code, und Daten brauchen keine Build-Pipeline.
Highlights
- SSE-Endpoint eingebaut —
/ssemit Heartbeat (15s), Bun-Idle-Timeout-Handling - Asynchroner Broadcast — Write-Handler emittiert Event, SSE-Consumer pickt es auf und broadcastet an verbundene Clients
- Pro Mandant getrennt — Clients sehen nur Events ihres Mandanten
- Multi-Stream-Projektion — aggregat-übergreifende Read-Models (z.B. Dashboard, das Events aus 5 Aggregaten zusammenführt)
- Dead-Letter-Queue — fehlgeschlagene Projektionen landen in einer eigenen Tabelle für Operations
- Saubere Multi-Instanz — bei mehreren API-Instanzen erhält jeder Client jedes Event genau einmal
Architektur-Tiefendoku
event-dispatcher— Async-Delivery, Dead-Letter, Retentionprojections— Single-Stream vs Cross-Aggregat
Wo das im Pitch landet
- PublicStatus-Showcase: Live-Updates auf der öffentlichen Seite = SSE-Demo
- DACH-Mittelstand: „Echtzeit-Kollaboration ohne Pusher-Abo, Schema-Änderungen ohne Deploy”
- Indie-Hacker: „Realtime ist von Haus aus da. Edit-and-See, nicht Edit-then-Deploy”
- Im Vergleich zu Retool / Supabase / Lovable: Kein Edit-Sync-Deploy-Loop. Designer schreibt, User sehen.