Questions every buyer asks. Pre-answered, honest, no marketing fluff.
Sorted into 4 blocks: Trust & lock-in · EU compliance · Operations · Pricing & migration.
Trust & lock-in
1. “What happens if you disappear tomorrow?”
Your app lives in your own Git repo as TypeScript code. If kumiko.so shuts down tomorrow:
- Your app keeps running — it doesn’t depend on our servers
- You deploy it yourself (Docker on Hetzner / Kubernetes / bare-metal)
- The framework and bundled features are public on GitHub under BSL-1.1 — full source access, fork allowed, your own development allowed
- Every release automatically becomes Apache-2.0 after 2 years — if we stop, the code becomes the community’s
Your app is as independent of us as a Linux server is of Linus Torvalds.
2. “We’re a large company. Who’s liable when something goes wrong?”
Enterprise contracts include SLA, support guarantees, and on request a source-code escrow with a notary. Standard for European mid-market with compliance requirements.
For kumiko.so Hosted plans, our SLA from the Pricing tier applies. For Self-Host, you’re responsible for operations (as with any open-source software).
3. “We hate vendor lock-in. How is that handled?”
Three layers:
- Your app code: lives in your repo. Platform-independent
- Your data: lives in your Postgres. Standard PG, no proprietary format.
pg_dumpout, into anywhere - The framework itself: public on GitHub under BSL-1.1, NPM packages free to use, forks allowed. No “cloud-only API” like Firebase. The only restriction: no commercial hosting platform that competes with kumiko.so (after 2 years that restriction expires too → Apache-2.0)
4. “Who’s already running this?”
Honest: We’re in the pilot phase in 2026. Live in production today: publicstatus.eu — a status-page platform that itself runs on Kumiko and serves multiple tenants with their own subdomain and branding.
We’re currently taking on 3–5 European mid-market customers as pilot users. Pilot means: a joint ~3-week setup sprint, then 3 months of guided rollout. If it works out, we’d love to use your story as a reference — with veto over every sentence.
5. “What if the pilot fails technically?”
Three layers of protection:
- Use-case audit before pilot start — we tell you honestly upfront if your case isn’t a fit (>100k events/sec, edge-compute mandatory, etc.). Better no pilot than a disappointed customer
- Setup sprint ends with a go/no-go decision — after 3 weeks you know if it holds. No commitment until then
- Code is yours from day one — even if you walk after the setup sprint, you keep everything we built together. Your repo, your database
6. “Can we fork Kumiko and develop it ourselves?”
Yes. Framework is public under BSL-1.1 on GitHub. You may:
- Fork for internal use — unrestricted
- Contribute patches and features — pull requests welcome
- Publish your own forks — as long as you don’t operate a commercial hosting platform that competes with kumiko.so
- After 2 years, every release becomes Apache-2.0 → that restriction expires too
In practice 95 % of use cases are covered by BSL. For edge cases: one quick conversation, we’ll find an arrangement.
EU compliance
7. “GDPR data-processing agreement (DPA) — what’s in it?”
For kumiko.so Hosted: standard DPA per GDPR Art. 28, hosting in Germany (Hetzner). Template ships before contract start for review by your data protection officer.
For Self-Host you’re both controller and processor — no DPA needed because no external processing.
8. “Schrems II risk? Data in US cloud?”
No. Default hosting is Hetzner Germany. Local LLM (Llama, Mistral via Ollama) means even AI requests don’t leave your data center. If you use Anthropic or OpenAI, that runs through your own contracts with the US providers (BYOK), not through us.
9. “What does the audit trail look like in practice?”
Every change to an entity is an event in the database. Three access paths:
- Via CLI:
yarn kumiko inspect <entity-id>→ complete history as a table - Via code:
ctx.loadAggregate(id, { asOf: '2026-03-12T14:32:00Z' })→ state at any point in time - Via web UI: audit tab per entity (shipping with the Designer, H2 2026)
ISO 27001 audit, GDPR access requests, internal review: each is one query instead of a sprint.
10. “What about GDPR erasure (right to be forgotten)?”
Crypto-shredding: PII fields are encrypted with user-specific keys. “Forget” = delete the key. The audit trail remains readable for compliance audits (event structure), personal data is mathematically illegible.
Detail: tech/audit-event-sourcing and architecture/es-gdpr-strategy.
11. “Can we run on-prem without internet?”
Yes. Own hardware, air-gapped setup, or Hetzner without outbound — all possible. Local LLM via Ollama runs on your own GPU server. Updates via signed container images, manual installation. Setup docs: tech/hosting-on-prem.
Operations
12. “What skills does my team need?”
- Minimum: TypeScript basics + SQL understanding. No event-sourcing vocabulary needed — Hello-World comes without it
- Mid-level: React + Postgres operations (migrations, backups). Standard stack
- Advanced: Event-sourcing concepts for complex domain models. Docs and examples included
Compared to other event-sourcing frameworks (Marten, Axon): a much lower entry barrier — you can build CRUD apps without writing a single “aggregate”.
13. “How fast is the database actually?”
Reproducible numbers from our test suite:
- Event append: several thousand per second under realistic load; on standard dev hardware we measure ≥3,000 events/sec under parallel-load test, ~14,000 events/sec isolated
- Database: Postgres scales into the billions of rows, that’s not our bottleneck
- API requests: Bun + Hono reach tens of thousands of requests/sec per instance, horizontally scalable
If you need >100,000 events/sec (trading platform, telemetry pipeline), Kafka or EventStoreDB belongs there, not Kumiko. For 99 % of business apps it’s plenty.
14. “What happens if the server dies? Restore story?”
Standard setup on Hetzner:
- Database backups: automatic daily Postgres snapshots, 30-day retention
- Off-site: additional backups on S3-compatible storage (Hetzner Storage Box or MinIO)
- Restore time (RTO): typically <2 hours after Hetzner server loss (new VM + restore snapshot + container restart)
- Data loss (RPO): ≤24h with daily snapshots, ≤5 min with WAL streaming (Pro tier)
- Restore drill: we recommend once per quarter — can be automated
For kumiko.so Hosted we run this. For Self-Host it’s your responsibility, with docs in tech/hosting-on-prem.
15. “How do updates work? Breaking changes?”
- Framework updates: semver. Patch releases are safe, minor brings new features (additive), major releases ship with migration guides
- Release cadence today: patches weekly, minor monthly, major at most 2× per year
- Breaking-change policy: no major without ≥3 months notice + codemod scripts where possible
- Update path on Self-Host: container image pin in your hand. You decide when you update
- Security patches: separate channel, patched ≤72 h after CVE disclosure
16. “Which versions, which dependencies?”
Stack today (as of 2026-05):
- Bun ≥ 1.2 (runtime), Postgres ≥ 15, Redis ≥ 7, Meilisearch ≥ 1.10 (optional)
- Native externals in the server bundle: argon2, drizzle-kit, drizzle-orm, ioredis, postgres, bullmq, temporal-polyfill (7 packages, version-pinned)
- Docker image size: ~270 MB for a typical Kumiko app
Stack docs: tech/hosting-on-prem.
Pricing & migration
17. “What does it actually cost?”
As of 2026-05 — pricing will be finalized Q3 2026 with the pilot customers. Current working draft:
| Tier | Price range | What’s in |
|---|---|---|
| Self-Host (Open Source) | €0 license | Framework + bundled features free to use. Hosting typically €50–150/month (Hetzner server incl. backup) |
| kumiko.so Pro (Hosted) | ~€49–149/month per app | Hosting in DE, custom domain, BYOK LLM, email support |
| kumiko.so Enterprise | Mid 4–5 figures p.a. | Dedicated instance, SLA, premium support, on-prem license available |
| Pilot program | €0 for 3 months | 3–5 slots, joint setup sprint, reference-story right (veto on every sentence) |
Pro tier is not per-user pricing — at 100 employees you don’t pay 100× more. The TCO advantage over Retool becomes significant at ~20+ users.
18. “How do we migrate from [Excel/Notion/Airtable/Retool/in-house build]?”
Per tool, different:
- Excel/Notion/Airtable: CSV export → schema generation. Days of work for a mid-size table
- Retool: UI gets regenerated, data source (Postgres) stays. 2–4 weeks for a mid-size tool
- In-house (Node/Django/Rails): depends on complexity. Migration audit is included in the pilot program
19. “What if the AI generates bad code?”
Four layers of protection:
- Designer as correction layer: you see what the AI generated, you can edit it visually — no code reading needed for standard patterns
- Custom code stays untouched: the patcher only edits recognized patterns. Your own handler bodies are not overwritten
- Validation loop: TypeScript check + tests + linter feed back to the AI. If tests fail, it corrects — until green
- Git history: every AI generation is a commit. Rollback via
git revert
20. “How do you prevent abuse from other tenants? Storage hog, mail spam, AI runaway?”
Structurally, not with monitoring band-aids. BYOK is the default, not a premium feature — what’s variably expensive runs through your accounts:
- Email send: Brevo, Postmark, SES — your SMTP key. When another tenant runs spam, their account burns, not a shared platform pool
- AI tokens: Anthropic, OpenAI or local model — your key. Cost explosion from bot loops hits the originator, not the platform pool
- File storage: BYO-S3 (Hetzner Object Storage / MinIO / AWS-S3). Storage-hog tenants fill their own bucket, not our Hetzner disk
On top of that, hard caps per tier (visible on pricing) for platform resources like egress and DB storage. Reaching a cap blocks write operations with a clear upgrade path — no surprise suspensions, no hidden clauses.
At disproportionate load (>10× tier median over 7 days) we talk to you in person. Fair use, not algorithm.
21. “How do you technically protect our app against other tenants and external attacks?”
Four layers, all standard, all verifiable in the docs:
- Cross-App isolation via Network-Policy: Every app runs in its own Kubernetes namespace with an egress firewall. An app can only reach the services it needs (own database, own Redis, selected external APIs). Lateral movement to other customer apps is technically impossible on the network level
- Container Hardening (Pod-Security-Standards): Containers run without root privileges, without privileged mode, without elevated Linux capabilities. A bug in one app cannot escape to the container host
- 3-Layer Rate-Limiting: Edge throttle on HTTP level (DDoS), strict auth-endpoint limit (brute force), plus per-handler rate-limits in the application code (domain-specific). Layers complement each other
- Backup encryption AES-256: Postgres WAL and K8s resource backups land encrypted on S3. Even with a compromised Hetzner account the backup data is unreadable without the encryption key
Plus on application layer: per-app database with its own Postgres role and GRANTs (cross-app DB reading technically impossible), field-level encryption for sensitive fields, Wireguard-VPN-only admin access (no public SSH).
Detail docs: Security Hardening.
Question not answered?
Pilot program / sales: hello@kumiko.so
Tech details: Framework for architecture overview, Docs for deep dives.