Kumiko Features: built for compliance, built for speed

For decision-makers

A complete change history without a separate audit-logging system — for a GDPR access request (Art. 15) or support („what happened on the 12th?”) the system returns the history including who, when and what. Supports audit requirements from SOC-2 or ISO-27001 reviews, but is not a substitute for certification.

For engineers

Event sourcing instead of a parallel audit log — every write produces an event, and the read state is built from those events. The history is the data itself, not an extra system that can drift out of sync.

For decision-makers

Sensitive fields encrypted at rest — salaries, health data and API tokens sit as ciphertext in a DB dump or a leaked backup. GDPR Art. 32 („appropriate technical measures”). Crypto-shredding for Art. 17: delete the key instead of overwriting millions of rows. BYOK (customer vault) is in progress.

For engineers

Encryption as a schema flag, not as application code — a field is marked encrypted at definition time and the framework handles encrypt and decrypt. Erasure by destroying the key instead of a row-by-row overwrite.

For decision-makers

Logical tenant separation — a bug in a tenant filter cannot trivially expose another customer's data, because isolation is enforced at the DB context. Compliance reviews get simpler: isolation is architecture, not a convention in application code.

For engineers

Isolation at the data-access layer, not re-checked in every handler — every request runs tenant-scoped automatically; cross-tenant access is an explicit exception, not the default path.

For decision-makers

The UI updates live — no manual reloads, no separate Pusher, Ably or Firebase. An estimated €200–500/month of realtime SaaS is avoidable, running over the existing HTTP stack.

For engineers

Server-Sent Events over the existing HTTP stack — no WebSocket cluster, no third party. Affected clients are notified automatically after every write.

For decision-makers

Features by prompt, not only by sprint — an LLM writes structured feature code that is validated before it runs, no blind execution of generated code. The Designer acts as a correction layer. Kumiko is positioned for AI-native app development.

For engineers

A declarative feature structure instead of free-form code — because features follow a fixed shape, an LLM can generate them and the framework can validate them before running, instead of trusting blindly.

For decision-makers

Auth flows done — sign-up, login, password reset, invite links for B2B onboarding, TOTP-based 2FA. Sessions are revocable (important when tokens are compromised, or MFA state changes).

For engineers

Passwords hashed, sessions revocable, TOTP MFA with QR enrollment and recovery codes — standard auth flows ready out of the box (Argon2 hashing), no home-grown auth implementation needed.

For decision-makers

Permissions declared centrally on handlers — roles are checked before a handler runs, and the UI can bind buttons to allowed actions. Fewer role checks scattered throughout the code.

For engineers

A role check right at each handler definition — authorization is part of the definition, not an ad-hoc check buried in the middle of the code.

For decision-makers

Access, erasure and portability automatable — a user exports their personal data, and account deletion calls registered hooks. Saves manual legal and ops hours per request, but is not a substitute for legal advice.

For engineers

Export and erasure as registered hooks per feature — each feature declares which data belongs to a person; export and forget then run automatically across all features.

For decision-makers

Email, in-app and push from a single call — no separate notification pipeline per channel. Per-user preferences and a delivery log for support and compliance.

For engineers

One call, multiple channels — the application triggers a notification, the framework fans it out to the enabled channels and logs every delivery attempt.

For decision-makers

PDFs, emails and exports run asynchronously — the user doesn't wait 30s for an HTTP response. Retries on transient failures; the operator sees failed runs and can re-trigger them.

For engineers

Proven queue technology (BullMQ on Redis) — no home-grown queue. Every run is logged, failed jobs are visible to the operator and retryable.

For decision-makers

Protection against brute-force and API abuse — configurable limits per user, IP or action. Prevents cost blow-ups from DDoS or frontend bugs, and fair-use per plan is possible.

For engineers

Limits right at the handler definition, not as a separate layer — configurable per route (IP, user, action), Redis-backed, with a standard HTTP 429 response and Retry-After.