FAQ: Häufige Fragen vor dem Kauf

Q: 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_dump raus, 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.rocks konkurriert (in 2 Jahren fällt auch das weg → Apache-2.0)

Q: Wer hat das schon im Einsatz?

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 DACH-Mittelständler als Pilot-Kunden auf. Fragt einfach an, ob gerade ein Platz frei ist. Pilot heißt: gemeinsamer ~3-Wochen-Setup-Sprint, danach 3 Monate Begleitung. Wenn's gut läuft, dürfen wir Eure Story als Case-Study nutzen, mit Vetorecht über jeden Satz.

Q: Was wenn das Pilot-Projekt technisch scheitert?

Drei Schichten Schutz: • Use-Case-Audit vor Pilot-Start: wir sagen Euch 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

Q: 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.rocks 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. ---

Fragen, die vor dem Kauf aufkommen, direkt beantwortet.

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.rocks 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.rocks 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_dump raus, 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.rocks konkurriert (in 2 Jahren fällt auch das weg → Apache-2.0)

4. „Wer hat das schon im Einsatz?”

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 DACH-Mittelständler als Pilot-Kunden auf. Fragt einfach an, ob gerade ein Platz frei ist. Pilot heißt: gemeinsamer ~3-Wochen-Setup-Sprint, danach 3 Monate Begleitung. Wenn’s gut läuft, dürfen wir Eure Story als Case-Study 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 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.rocks 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.rocks 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. „Wo liegen unsere Daten?”

Standard-Hosting ist Hetzner Deutschland, Backups liegen in der EU. Cloudflare ist als DNS und DDoS-Schutz vorgeschaltet (Details in der Liste der Unterauftragsverarbeiter). 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: bun 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: Event-Sourcing und Änderungsprotokoll.

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: Hosting und 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.rocks Hosted übernehmen wir das. Bei Self-Host ist es Eure Verantwortung, mit Doku in Hosting und 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: Hosting und On-Prem.

Pricing & Migration

17. „Was kostet das wirklich?”

Endgültige Preise gibt es noch nicht, sie kommen nicht vor Q1 2027. Die Beträge sind Richtwerte aus dem aktuellen Entwurf:

Tier	Richtwert	Was drin
Self-Host (Open Source)	0 € Lizenz	Framework + Bausteine frei nutzbar. Hosting ab rund 10 €/Monat für eine einzelne App, mehr je nach Traffic und mitbetriebenen Bausteinen
kumiko.rocks Pro (Hosted)	ab 49 € im Monat pro App	Hosting in DE, eigene Domain, BYOK-LLM, E-Mail-Support
kumiko.rocks Enterprise	4–5-stellig p.a.	Dedizierte Instanz, SLA, Premium-Support, On-Prem-Lizenz möglich
Pilot-Programm	0 € für 3 Monate	Plätze auf Anfrage, gemeinsamer Setup-Sprint, Case-Study-Recht

Zum Vergleich: Unsere eigene Plattform mit allen Apps läuft auf einem einzigen Server für 60 €/Monat.

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, mit Eurem eigenen SMTP-Schlüssel. Wenn ein anderer Tenant Spam fährt, brennt sein Brevo-Account, nicht der gemeinsame
KI-Tokens: Anthropic, OpenAI oder lokales Modell, mit Eurem eigenen 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).

Frage nicht beantwortet?

Pilot-Programm / Sales: [email protected]

Tech-Details: Framework für Architektur-Übersicht, Doku für Tiefendoku.