Kumiko Features: auf Compliance und Tempo gebaut

Für Entscheider

Vollständiger Änderungsverlauf ohne separates Audit-Logging — bei DSGVO-Auskunft (Art. 15) oder Support („Was passierte am 12.03.?”) liefert das System die Historie inkl. Wer/Wann/Was. Unterstützt Audit-Anforderungen aus SOC-2- oder ISO-27001-Reviews, ersetzt aber keine Zertifizierung.

Für Entwickler

Event Sourcing statt paralleles Audit-Log — jeder Write erzeugt ein Event, der Lesezustand wird daraus gebaut. Die Historie ist der Datenbestand selbst, kein zusätzliches System, das aus dem Ruder laufen kann.

Für Entscheider

Sensible Felder verschlüsselt at-rest — Gehälter, Gesundheitsdaten, API-Tokens liegen bei DB-Dump oder Backup-Leak nur als Ciphertext vor. DSGVO Art. 32 („geeignete technische Maßnahmen”). Crypto-Shredding für Art. 17: Schlüssel löschen statt Millionen Rows überschreiben. BYOK (Customer-Vault) ist in Arbeit.

Für Entwickler

Verschlüsselung als Schema-Flag, nicht als App-Code — ein Feld wird bei der Definition als verschlüsselt markiert, das Framework übernimmt Ver- und Entschlüsselung. Löschung per Schlüssel-Vernichtung statt Row-für-Row-Overwrite.

Für Entscheider

Logische Mandantentrennung — ein Bug im Tenant-Filter kann nicht trivial Daten anderer Kunden exponieren, weil die Isolation im DB-Context erzwungen wird. Compliance-Reviews werden einfacher: Isolation ist Architektur, nicht Konvention im App-Code.

Für Entwickler

Isolation im Datenzugriffs-Layer, nicht in jedem Handler neu geprüft — jede Anfrage läuft automatisch tenant-scoped; Cross-Tenant-Zugriff ist ein expliziter Ausnahmefall, kein Standardpfad.

Für Entscheider

Die UI aktualisiert sich live — keine manuellen Reloads, kein separates Pusher, Ably oder Firebase. Geschätzt ca. 200–500 €/Monat Realtime-SaaS einsparbar, läuft über den bestehenden HTTP-Stack.

Für Entwickler

Server-Sent Events über den bestehenden HTTP-Stack — kein WebSocket-Cluster, kein Drittanbieter. Betroffene Clients werden nach jedem Write automatisch benachrichtigt.

Für Entscheider

Features per Prompt statt nur per Sprint — ein LLM schreibt strukturierten Feature-Code, der vor dem Ausführen validiert wird, kein blindes Ausführen generierten Codes. Der Designer dient als Korrektur-Schicht. Kumiko ist damit für AI-native App-Entwicklung positioniert.

Für Entwickler

Deklarative Feature-Struktur statt freier Code — weil Features einem festen Aufbau folgen, kann ein LLM sie generieren und das Framework sie vor dem Ausführen validieren, statt blind zu vertrauen.

Für Entscheider

Auth-Flows fertig — Sign-Up, Login, Password-Reset, Invite-Links für B2B-Onboarding, TOTP-basierte 2FA. Sessions sind widerrufbar (wichtig bei kompromittierten Tokens oder MFA-Statusänderung).

Für Entwickler

Passwörter gehasht, Sessions widerrufbar, TOTP-MFA mit QR-Setup und Recovery-Codes — Standard-Auth-Flows fertig aus der Box (Argon2-Hashing), keine eigene Auth-Implementierung nötig.

Für Entscheider

Permissions zentral an Handlern — Rollen werden vor der Handler-Ausführung geprüft, die UI kann Buttons an erlaubte Actions koppeln. Weniger verstreute Rollen-Abfragen quer durch den Code.

Für Entwickler

Rollen-Check direkt an jeder Handler-Definition — Berechtigung ist Teil der Definition, nicht eine verstreute Ad-hoc-Prüfung mitten im Code.

Für Entscheider

Auskunft, Löschen, Portabilität automatisierbar — der User exportiert seine personenbezogenen Daten, eine Konto-Löschung ruft registrierte Hooks auf. Spart manuelle Juristen- und Ops-Stunden pro Anfrage, ersetzt aber keine Rechtsberatung.

Für Entwickler

Export und Löschung als registrierte Hooks pro Feature — jedes Feature meldet an, welche Daten zu einer Person gehören; Export und Forget laufen dann automatisch über alle Features hinweg.

Für Entscheider

E-Mail, In-App und Push aus einem Aufruf — keine eigene Notification-Pipeline pro Kanal. Preferences pro User, ein Delivery-Log für Support und Compliance.

Für Entwickler

Ein Aufruf, mehrere Kanäle — die Anwendung löst eine Benachrichtigung aus, das Framework fächert sie auf die aktivierten Kanäle auf und protokolliert jeden Zustellversuch.

Für Entscheider

PDF, E-Mail und Exporte asynchron — der User wartet nicht 30s auf eine HTTP-Antwort. Retries bei transienten Fehlern; der Operator sieht fehlgeschlagene Runs und kann sie erneut anstoßen.

Für Entwickler

Bewährte Queue-Technologie (BullMQ auf Redis) — keine selbstgebaute Queue. Jeder Lauf wird protokolliert, fehlgeschlagene Jobs sind für den Operator sichtbar und retry-bar.

Für Entscheider

Schutz vor Brute-Force und API-Abuse — konfigurierbare Limits pro User, IP oder Action. Verhindert Kosten-Explosionen bei DDoS oder Frontend-Bugs, Fair-Use pro Plan ist möglich.

Für Entwickler

Limits direkt an der Handler-Definition, nicht als separater Layer — pro Route konfigurierbar (IP, User, Aktion), Redis-basiert, mit Standard-HTTP-429-Antwort und Retry-After.