Tech detail

Multi-tenant — built-in, not DIY

Tenant scoping is the default, not opt-in. Every entity is tenant-isolated unless you mark it cross-tenant explicitly.

Tech USP: Tenant scoping is the default, not opt-in. Every entity is tenant-isolated unless you explicitly mark it cross-tenant.

Buyer’s view: One instance hosts any number of tenants. Each customer sees only their own data — automatically, without your engineers writing a single filter clause by hand.

Highlights

DB access is always tenant-scoped — no raw query can bypass it
Cross-tenant access is explicit, not implicit
Tenant resolution via header, cookie, resolver or default — fits subdomain, path and header-based setups
Anonymous-access for public endpoints with tenant resolution via host
Per tenant: own search index (Meilisearch), own feature toggles, own configuration

Architecture deep dive

tenant-db-context — ctx.db scoping, cross-tenant escalation
permissions — roles + ownership filter
scaling — multi-tenant scaling (DB-shared vs DB-per-tenant)

Where this lands in the pitch

EU mid-market: Top argument — every internal tool needs tenant separation as soon as more than one department uses it
Indie hackers: Explicit argument under “backend pain” — multi-tenant scoping is the #1 bug source in B2B SaaS

Other tech USPs

Auth + permissions — roles, field access, ownership, sessions

Login and permissions aren't something you build — they're the framework default. Email/password, JWT, sessions, roles, field-level access, row ownership.

BYOK + local LLM — no AI vendor lock-in

All AI calls go through one OpenAI-compatible adapter. Anthropic, OpenAI, Llama, vLLM — interchangeable via env-var, no code change.

Config-driven — Designer and AI edit the same code

Source of truth is your feature file. Designer (visual editor) and AI builder (prompt) produce the same output via a code patcher.

Extensibility — bundled features are optional

The framework is lean. Auth, sessions, notifications, audit, files, jobs are bundled building blocks — not mandatory.

Audit by default — Event Sourcing as a framework primitive

Every change to an entity is an event. The audit trail isn't something you build — it IS the framework.

Hosting + on-prem — you choose where it runs

Kumiko apps are standard Bun containers. Coolify, Hetzner, Kubernetes, bare-metal — all work.

Realtime — live updates without WebSocket plumbing

Realtime is default, not add-on. Server-Sent Events instead of WebSocket setup. Cross-aggregate updates via multi-stream projections.

Next step

Let's talk.

Pilot program open for European mid-market and indie hackers. Source access on request.

Built with itself · publicstatus.eu in production

hello@kumiko.so → Read the docs