Fragen die jeder Käufer stellt. Vorbeantwortet, ehrlich, ohne Marketing-Sprech.
Sortiert in 4 Blöcke: Vertrauen & Lock-in · DACH-Compliance · Betrieb & Operations · Pricing & Migration.
Vertrauen & Lock-in
1. „Was passiert, wenn Ihr morgen weg seid?”
Eure App lebt in Eurem eigenen Git-Repo als TypeScript-Code. Wenn kumiko.so morgen abschaltet:
- Eure App läuft weiter — sie hängt nicht an unseren Servern
- Ihr deployed sie selbst weiter (Docker auf Hetzner / Kubernetes / Bare-Metal)
- Framework und Bausteine sind öffentlich auf GitHub unter BSL-1.1 — voller Source-Zugang, forken erlaubt, eigene Weiterentwicklung erlaubt
- Jede Version wird nach 2 Jahren automatisch zu Apache-2.0 — wenn wir aufhören, gehört der Code der Community
Eure App ist genauso unabhängig von uns wie ein Linux-Server von Linus Torvalds.
2. „Wir sind in einer großen Firma. Wer haftet wenn was schiefgeht?”
Enterprise-Verträge inkludieren SLA, Support-Garantien, und auf Wunsch eine Source-Code-Hinterlegung beim Notar (Escrow). Für DACH-Mittelstand mit Compliance-Anforderungen ist das Standard.
Bei kumiko.so Hosted-Tarifen gilt unser SLA aus dem Pricing-Tier. Bei Self-Host seid Ihr selbst verantwortlich für den Betrieb (wie auch bei jeder Open-Source-Software).
3. „Wir wollen kein Vendor-Lock-in. Wie ist das geregelt?”
Drei Schichten:
- Eure App-Code: liegt in Eurem Repo. Plattform-unabhängig
- Daten: liegen in Eurer Postgres. Standard-PG, kein proprietäres Format.
pg_dumpraus, woanders rein - Framework selbst: Open-Source auf GitHub unter BSL-1.1, NPM-Pakete frei nutzbar, Forks erlaubt. Kein „Cloud-only API” wie bei Firebase. Einzige Einschränkung: keine kommerzielle Hosting-Plattform die mit kumiko.so konkurriert (in 2 Jahren fällt auch das weg → Apache-2.0)
4. „Wer hat das schon im Einsatz?”
Ehrlich: Wir sind 2026 in der Pilot-Phase. Heute produktiv: publicstatus.eu — eine Statuspage-Plattform die selbst auf Kumiko läuft und mehrere Tenants mit eigener Subdomain und Branding bedient.
Wir nehmen aktuell 3–5 DACH-Mittelständler als Pilot-Kunden auf. Pilot heißt: gemeinsamer ~3-Wochen-Setup-Sprint, danach 3 Monate Begleitung. Wenn’s gut läuft, dürfen wir Eure Story als Reference nutzen — mit Vetorecht über jeden Satz.
5. „Was wenn das Pilot-Projekt technisch scheitert?”
Drei Schichten Schutz:
- Use-Case-Audit vor Pilot-Start — wir sagen Euch ehrlich vorher wenn Euer Use-Case nicht passt (>100k Events/Sekunde, Edge-Compute-Pflicht, etc.). Lieber kein Pilot als enttäuschter Kunde
- Setup-Sprint endet mit Go/No-Go-Entscheidung — nach 3 Wochen wisst Ihr ob’s trägt. Bis dahin keine Verpflichtung
- Code gehört Euch ab Tag 1 — selbst wenn Ihr nach Setup-Sprint aussteigt, behaltet Ihr alles was wir zusammen gebaut habt. Eigenes Repo, eigene Datenbank
6. „Können wir Kumiko forken und selbst weiterentwickeln?”
Ja. Framework ist öffentlich unter BSL-1.1 auf GitHub. Ihr dürft:
- Forken für interne Nutzung — uneingeschränkt
- Eigene Patches und Features beitragen — Pull Requests willkommen
- Eigene Forks veröffentlichen — solange Ihr keine kommerzielle Hosting-Plattform betreibt, die mit kumiko.so konkurriert
- Nach 2 Jahren wird jede Version automatisch Apache-2.0 → dann fällt auch diese Einschränkung weg
In der Praxis sind 95 % der Anwendungsfälle durch BSL gedeckt. Bei Edge-Cases: einmal kurz sprechen, wir finden eine Vereinbarung.
DACH/EU-Compliance
7. „DSGVO-Auftragsverarbeitung (AVV) — was steht drin?”
Bei kumiko.so Hosted: Standard-AVV nach DSGVO Art. 28, Hosting in Deutschland (Hetzner). Vorlage schicken wir vor Vertragsbeginn zur Prüfung durch Euren Datenschutzbeauftragten.
Bei Self-Host seid Ihr Verantwortlicher und Verarbeiter zugleich — keine AVV nötig, weil keine externe Verarbeitung.
8. „Schrems-II-Risiko? Daten in US-Cloud?”
Nein. Standard-Hosting ist Hetzner Deutschland. Lokales Sprachmodell (Llama, Mistral via Ollama) bedeutet auch KI-Anfragen verlassen Euer Rechenzentrum nicht. Wenn Ihr Anthropic oder OpenAI nutzt, läuft das über Eure eigenen Verträge mit den US-Anbietern (BYOK), nicht über uns.
9. „Wie sieht das Änderungsprotokoll in der Praxis aus?”
Jede Änderung an einer Entität ist ein Event in der Datenbank. Drei Zugänge:
- Per CLI:
yarn kumiko inspect <entity-id>→ komplette Historie als Tabelle - Per Code:
ctx.loadAggregate(id, { asOf: '2026-03-12T14:32:00Z' })→ Zustand zu beliebigem Zeitpunkt - Per Web-UI: Änderungs-Tab pro Entität (kommt mit dem Designer, ab H2 2026)
ISO-27001-Audit, DSGVO-Auskunft, interne Revision: jeweils eine Abfrage statt eines Sprints.
10. „Was ist mit DSGVO-Erasure (Recht auf Vergessenwerden)?”
Crypto-Shredding: persönliche Felder werden mit nutzer-spezifischen Schlüsseln verschlüsselt. „Vergessen” = Schlüssel löschen. Das Änderungsprotokoll bleibt für Compliance-Audits lesbar (Event-Struktur), persönliche Daten sind mathematisch unleserlich.
Detail: tech/audit-event-sourcing und architecture/es-gdpr-strategy.
11. „Können wir On-Prem ohne Internet betreiben?”
Ja. Eigene Hardware, Air-Gapped-Setup, oder Hetzner ohne ausgehende Verbindungen — alles möglich. Lokales Sprachmodell via Ollama läuft auf eigenem GPU-Server. Updates über signierte Container-Images, manuelle Installation. Setup-Doku: tech/hosting-on-prem.
Betrieb & Operations
12. „Welche Skills braucht mein Team?”
- Minimum: TypeScript-Grundlagen + SQL-Verständnis. Kein Event-Sourcing-Vokabular nötig — Hello-World kommt ohne aus
- Mittel: React + Postgres-Operations (Migrationen, Backups). Standard-Stack
- Fortgeschritten: Event-Sourcing-Konzepte für komplexe Domain-Modelle. Doku + Beispiele liegen bei
Im Vergleich zu anderen Event-Sourcing-Frameworks (Marten, Axon): deutlich niedrigere Einstiegshürde — Ihr könnt CRUD-Apps bauen ohne ein einziges „Aggregate” zu schreiben.
13. „Wie schnell ist die Datenbank wirklich?”
Belastbare Zahlen aus dem Test-Suite:
- Events anhängen: mehrere tausend pro Sekunde unter realer Last; auf Standard-Dev-Hardware messen wir ≥3.000 Events/s im Parallel-Load-Test, isoliert ~14.000 Events/s
- Datenbank: Postgres skaliert in die Milliarden Zeilen, das ist nicht unser Bottleneck
- API-Anfragen: Bun + Hono erreichen mehrere zehntausend Requests/s pro Instanz, horizontal skalierbar
Wenn Ihr >100.000 Events/Sekunde braucht (Trading-Plattform, Telemetry-Pipeline), gehört Kafka oder EventStoreDB hin, nicht Kumiko. Für 99 % der Geschäftsanwendungen reicht es deutlich.
14. „Was passiert wenn der Server stirbt? Restore-Story?”
Standard-Setup auf Hetzner:
- Datenbank-Backups: automatische tägliche Postgres-Snapshots, 30-Tage-Aufbewahrung
- Off-Site: zusätzliche Backups auf S3-kompatiblen Storage (Hetzner Storage Box oder MinIO)
- Restore-Zeit (RTO): typisch <2 Stunden bei Hetzner-Server-Verlust (neue VM + Snapshot zurückspielen + Container-Restart)
- Datenverlust (RPO): ≤24h bei tägl. Snapshot, ≤5min mit WAL-Streaming (Pro-Tier)
- Restore-Drill: wir empfehlen 1× pro Quartal — kann automatisiert werden
Bei kumiko.so Hosted übernehmen wir das. Bei Self-Host ist es Eure Verantwortung, mit Doku in tech/hosting-on-prem.
15. „Wie funktionieren Updates? Breaking Changes?”
- Framework-Updates: Semver. Patch-Releases sind sicher, Minor bringt neue Features (additiv), Major-Releases haben Migrations-Anleitung
- Release-Kadenz heute: Patch wöchentlich, Minor monatlich, Major maximal 2× pro Jahr
- Breaking-Change-Policy: kein Major ohne ≥3 Monate Vorlauf + Codemod-Skripte wo möglich
- Update-Pfad bei Self-Host: Container-Image-Pin in Eurer Hand. Wann Ihr updated, entscheidet Ihr
- Sicherheits-Patches: separater Channel, ≤72h ab CVE-Veröffentlichung gepatcht
16. „Welche Versionen, welche Abhängigkeiten?”
Stack heute (Stand 2026-05-02):
- Bun ≥ 1.2 (Runtime), Postgres ≥ 15, Redis ≥ 7, Meilisearch ≥ 1.10 (optional)
- Native Externals im Server-Bundle: argon2, drizzle-kit, drizzle-orm, ioredis, postgres, bullmq, temporal-polyfill (7 Pakete, version-pinned)
- Docker-Image-Größe: ~270 MB für eine typische Kumiko-App
Stack-Doku: tech/hosting-on-prem.
Pricing & Migration
17. „Was kostet das wirklich?”
Stand 2026-05-02 — Pricing wird Q3 2026 mit den Pilot-Kunden finalisiert. Aktueller Working-Draft:
| Tier | Pricing-Range | Was drin |
|---|---|---|
| Self-Host (Open Source) | 0 € Lizenz | Framework + Bausteine frei nutzbar. Hosting-Kosten typisch 50–150 €/Monat (Hetzner-Server inkl. Backup) |
| kumiko.so Pro (Hosted) | ~49–149 €/Monat pro App | Hosting in DE, eigene Domain, BYOK-LLM, E-Mail-Support |
| kumiko.so Enterprise | 4–5-stellig p.a. | Dedizierte Instanz, SLA, Premium-Support, On-Prem-Lizenz möglich |
| Pilot-Programm | 0 € für 3 Monate | 3–5 Slots, gemeinsamer Setup-Sprint, Reference-Story-Recht |
Pro-Tier-Preise sind kein Pro-User-Pricing — bei 100 Mitarbeitern zahlt Ihr nicht 100× mehr. Der TCO-Vorteil gegen Retool wird ab ~20 Usern signifikant.
18. „Wie migrieren wir von [Excel/Notion/Airtable/Retool/Eigenbau]?”
Pro Tool unterschiedlich:
- Excel/Notion/Airtable: CSV-Export → Schema-Generation. Tagessache für eine mittelgroße Tabelle
- Retool: UI wird neu generiert, Datenquelle (Postgres) bleibt. 2–4 Wochen für ein mittleres Tool
- Eigenbau (Node/Django/Rails): abhängig von Komplexität. Migrations-Audit ist im Pilot-Programm enthalten
19. „Was wenn die KI Fehler macht?”
Vier Schichten Schutz:
- Designer als Korrektur-Layer: Ihr seht was die KI generiert hat, könnt es visuell anpassen — kein Code-Lesen nötig für Standard-Muster
- Custom-Code bleibt unangetastet: der Patcher editiert nur erkannte Muster. Eure eigenen Handler-Bodies werden nicht überschrieben
- Validation-Loop: TypeScript-Check + Tests + Linter geben Feedback an die KI. Wenn Tests rot, korrigiert sie nach — bis grün
- Git-History: jede KI-Generation ist ein Commit. Rollback per
git revert
20. „Wie verhindert Ihr Abuse durch andere Tenants? Datengrab, Mail-Schleuder, KI-Spam?”
Strukturell statt mit Monitoring-Pflastern. BYOK ist Default, nicht Premium-Feature — was variabel teuer ist, läuft über Eure Konten:
- E-Mail-Versand: Brevo, Postmark, SES — Euer SMTP-Schlüssel. Wenn ein anderer Tenant Spam fährt, brennt sein Brevo-Account, nicht der gemeinsame
- KI-Tokens: Anthropic, OpenAI oder lokales Modell — Euer Schlüssel. Cost-Explosion durch Bot-Loops trifft den Verursacher, nicht den Plattform-Pool
- File-Storage: BYO-S3 (Hetzner Object Storage / MinIO / AWS-S3). Datengrab-Tenants füllen ihren eigenen Bucket, nicht unsere Hetzner-Disk
Plus harte Caps pro Tier (sichtbar in pricing) für Plattform-Ressourcen wie Egress und DB-Storage. Cap-Erreichung blockt Schreibe-Operationen mit klarem Upgrade-Pfad — keine Überraschungs-Suspensions, keine versteckten Klauseln.
Bei unverhältnismäßiger Last (>10× Tier-Median über 7 Tage) reden wir mit Euch persönlich. Fair-Use, nicht Algorithmus.
21. „Wie schützt Ihr unsere App technisch gegen andere Mandanten und gegen Angriffe von außen?”
Vier Schichten, alle Standard, alle in der Doku überprüfbar:
- Cross-App-Isolation per Network-Policy: Jede App läuft in eigenem Kubernetes-Namespace mit Egress-Firewall. Eine App kann ausgehend nur zu den nötigen Diensten reden (eigene Datenbank, eigenes Redis, ausgewählte externe APIs). Lateral-Movement zu anderen Customer-Apps ist auf Netzwerk-Ebene technisch nicht möglich
- Container-Hardening (Pod-Security-Standards): Container laufen ohne Root-Rechte, ohne Privileged-Mode, ohne erweiterte Linux-Capabilities. Ein Bug in einer App kann nicht zu Container-Escape führen
- 3-Layer Rate-Limiting: Edge-Drossel auf HTTP-Ebene (DDoS), Auth-Endpoint-Strict-Limit (Brute-Force), plus per-Handler-Rate-Limits im Application-Code (Domain-spezifisch). Schichten ergänzen sich
- Backup-Encryption AES-256: Postgres-WAL und K8s-Resource-Backups landen verschlüsselt auf S3. Selbst bei Hetzner-Account-Compromise sind die Backup-Daten ohne Encryption-Key nicht lesbar
Plus auf Application-Layer: per-App-Datenbank mit eigener Postgres-Role und GRANTs (Cross-App-DB-Lesen technisch unmöglich), Field-Level-Encryption für sensitive Felder, Wireguard-VPN-only Admin-Zugang (kein public SSH).
Detail-Doku: Security-Hardening.
Frage nicht beantwortet?
Pilot-Programm / Sales: hello@kumiko.so
Tech-Details: Framework für Architektur-Übersicht, Doku für Tiefendoku.