Tech USP: Realtime is default, not add-on. Server-Sent Events (SSE) instead of WebSocket setup. Cross-aggregate updates via multi-stream projections — and schema changes go live in seconds, without a redeploy.
Buyer’s view: Live updates like status pages, chats or dashboards work without a Pusher/Ably subscription. Edit a form in the Designer at 14:32 — your users see the new field at 14:32:03. No build, no deploy, no “wait for the next release”.
The big differentiator: schema changes without redeploy
Most internal-tools platforms have an edit-then-sync cycle. Retool: edit in the editor, hit “Save”, users get the new dashboard on next reload. Supabase: change a table, regenerate types, redeploy your app. Lovable / v0: prompt → regenerate the whole project → deploy → wait for the new build.
Kumiko skips that loop. The Designer (or AI builder) writes your schema change to the running app’s database. The app reads its own schema and broadcasts the change over SSE. Connected users see the new field, the new view, the new role rule — in seconds, while still on the same page.
| What happens | Time to see it live |
|---|---|
| Add a field to a form | Seconds, no reload needed |
| Add a new view (e.g. “tickets by department”) | Seconds, no reload needed |
| Change a permission rule | Seconds, applied on next request |
| Add a whole new entity (e.g. “vendors”) | Seconds, schema migrates inline, users see it on next nav |
Why this matters for buyers: “We changed a field, the app needed a redeploy, deploy failed, half the warehouse was offline for an hour” — that’s the failure mode you’re paying us to eliminate. Schema changes are data, not code, and data doesn’t need a build pipeline.
Highlights
- SSE endpoint built in —
/ssewith heartbeat (15s), Bun idle-timeout handling - Async broadcast — write handler emits an event, SSE consumer picks it up and broadcasts to connected clients
- Per-tenant separation — clients only see events from their own tenant
- Multi-stream projection — cross-aggregate read models (e.g. dashboard pulling events from 5 aggregates)
- Dead-letter queue — failed projections land in a dedicated table for ops
- Clean multi-instance — with multiple API instances, each client receives each event exactly once
Architecture deep dive
event-dispatcher— async delivery, dead letter, retentionprojections— single-stream vs cross-aggregate
Where this lands in the pitch
- PublicStatus showcase: Live updates on the public page = SSE demo
- EU mid-market: “Live collaboration without a Pusher subscription, schema changes without a deploy”
- Indie hackers: “Realtime works out of the box. Edit-and-see, not edit-then-deploy”
- Compared to Retool / Supabase / Lovable: No edit-sync-deploy loop. Designer writes, users see.