Kurzfassung: Next.js+Prisma, Ruby on Rails und Supabase sind drei unterschiedliche, aber alle drei bewährte Wege, ein Backend selbst zu bauen — mit riesigem Ökosystem, viel Doku und Entwicklern, die ihr am Markt findet. Wenn Euer Team genau diesen Stack schon kann und die Zeit hat, Mandantentrennung, Audit-Trail und Rollenmodell selbst zu verkabeln, ist das ein solider Weg. Bei Kumiko baut Ihr per KI-Chat iterativ am Feature — und Ihr bekommt trotzdem echten, editierbaren Code in Eurem Repo, keine Blackbox. Vollständige Text-zu-Feature-Generierung ist Kern-Feature ab H2 2026.
Für wen dieser Vergleich gedacht ist
Dieser Vergleich richtet sich an Engineering-Leads und CTOs, die gerade eine Stack-Entscheidung für ein neues internes Tool, Portal oder B2B-SaaS-Produkt treffen:
- Teams, die zwischen “wir bauen es selbst mit einem bewährten Framework” und “wir lassen es generieren” abwägen
- Projekte mit Mandantentrennung, Rollenmodell, Audit-Trail oder DSGVO-Anforderungen von Tag 1
- Teams, die schon einen Next.js-, Rails- oder Supabase-Hintergrund haben und wissen wollen, was sie mit Kumiko eintauschen
Wenn Euer Team bereits tief in einem der drei Stacks sitzt, dieser Stack für Euch funktioniert und Ihr keinen Grund zum Wechseln habt — dann ist “bei Eurem Stack bleiben” oft die richtige Antwort. Dieser Vergleich ist für den Moment gedacht, in dem Ihr neu entscheidet.
Was die drei Alternativen sind
Next.js + Prisma: Der heute wohl verbreitetste TypeScript-Stack für Web-Apps. Next.js für Routing, Rendering und API-Routes, Prisma als Type-Safe-ORM über Postgres/MySQL/SQLite. Riesiges npm-Ökosystem, React-Team-Skills sind überall verfügbar. Ihr baut Auth, Mandantentrennung, Audit-Trail und Admin-UI selbst — meist mit weiteren Libraries (NextAuth, eigene Middleware) oder von Hand.
Ruby on Rails: Batteries-included-Framework seit 2004, MVC, ActiveRecord als ORM. Convention-over-Configuration bedeutet: viel kommt fertig mit (Migrations, Background-Jobs via Sidekiq, Mailer), aber Mandantentrennung, feingranulare Rollen und ein lückenloses Audit-Log sind auch hier Euer Job — meist über Gems wie pundit, paper_trail oder acts_as_tenant.
Supabase: Backend-as-a-Service auf Postgres-Basis — Login, Realtime, Storage, Edge-Functions als Dienste. Ihr schreibt SQL und Row-Level-Security-Policies, Supabase hostet das. Separater ausführlicher Vergleich verfügbar.
Alle drei sind reife, bewährte Wege mit riesigen Communities. Der Unterschied zu Kumiko liegt nicht in der Qualität, sondern im Wer baut was: bei allen dreien baut Ihr das App-Skelett (Mandanten, Rollen, Audit, Admin-UI) selbst — bei Kumiko baut Ihr es mit KI-Chat-Unterstützung, und Ihr behaltet trotzdem den vollen, editierbaren Code (vollautomatische Generierung aus reinem Text ist Kern-Feature ab H2 2026).
Wo sie stärker sind
Ehrlich:
- Ökosystem-Größe: npm hat weit über 2 Millionen Pakete, RubyGems Zehntausende ausgereifte Gems. Für jedes Nischenproblem gibt es wahrscheinlich schon eine Library
- Talent-Pool: Next.js- und Rails-Entwickler findet Ihr auf jedem Jobportal. Kumiko-Entwickler lernt Ihr an — die Lernkurve ist real
- Reife und Battle-Testing: Rails läuft seit über 20 Jahren in Produktion bei Shopify, GitHub, Basecamp. Next.js treibt einen großen Teil des modernen Web an. Kumiko ist deutlich jünger
- Freiheit bei der Architektur: Ihr könnt jedes Datenmodell, jede Bibliothek, jeden Rendering-Ansatz wählen — kein Framework-Vertrag, der Euch auf einen Pfad festlegt
- Mobile- und Third-Party-Integrationen: Für exotische Anbindungen (Zahlungsdienstleister, CRMs, Legacy-Systeme) gibt es in beiden Ökosystemen fast immer schon eine fertige Library
Das ist wichtig, weil Kumiko nicht gewinnen muss, wenn Euer Team den Stack schon beherrscht, die Zeit für den Eigenbau hat und maximale architektonische Freiheit braucht. Genau dort sind Next.js+Prisma und Rails stark.
Wo Kumiko stärker ist
| Aspekt | Next.js + Prisma | Rails | Supabase | Kumiko |
|---|---|---|---|---|
| Zeit bis zur laufenden App | Wochen — Auth, Mandanten-Scoping, Audit, Admin-UI selbst bauen | Tage bis Wochen — mehr kommt fertig mit, Mandanten/Audit trotzdem Handarbeit | DB in Minuten da, Rest (Login-Verkabelung, RLS, Frontend, Audit) selbst | Unter 2 Minuten von Klick zu Live-URL — Login, Multi-Tenant, Audit, Realtime, Admin-UI inklusive |
| Backend-Generierung | Ihr schreibt jede Route, jedes Model | Ihr schreibt jedes Model, jeden Controller | Ihr schreibt SQL + RLS-Policies | KI-Chat patcht/erweitert Features interaktiv, Ihr editiert den Code (volle Text-zu-Feature-Generierung ab H2 2026) |
| Mandantentrennung | Selbst bauen (Middleware, Row-Scoping) | Selbst bauen (Gem wie acts_as_tenant) | Selbst bauen (RLS-Policies pro Tabelle) | Eingebaut — jede Entität ist tenant-scoped |
| Änderungsprotokoll | Selbst bauen | Gem wie paper_trail | Selbst bauen (Trigger oder eigene Tabelle) | Eingebaut — jede Schreiboperation ist ein Event |
| Rollen/Access Control | Selbst bauen oder Library (z. B. CASL) | Gem wie pundit/cancancan | RLS-Policies pro Tabelle | Deklarativ pro Handler, Feature-Toggle- und Tier-fähig |
| Background-Jobs mit Audit-Trail | Library (BullMQ o. ä.), Logging selbst | Sidekiq, Logging selbst | Edge-Functions, Logging selbst | Eingebaut inkl. Operator-UI + Run-Log |
| Schema-Änderungen live | Deploy nötig | Deploy nötig | Deploy nötig | Designer-Edit → Nutzer sehen es in Sekunden, ohne Reload |
| DACH/EU-Hosting | Beliebiger Host (Eure Entscheidung) | Beliebiger Host (Eure Entscheidung) | EU-Region möglich | Hetzner / On-Prem / Bare-Metal Default |
| Lock-in | Niedrig — Standard-Stack, Code in Eurem Repo | Niedrig — Standard-Stack, Code in Eurem Repo | Mittel (OSS, aber Hosting-Stack groß) | Niedrig — generierter Code in Eurem Repo, Framework öffentlich unter BSL (→ Apache-2.0 nach 2 Jahren) |
| Ökosystem-Größe | Riesig (npm) | Groß (RubyGems) | Groß | Klein — bundled Features statt Marktplatz |
Die kaufrelevanten Unterschiede in der Praxis
1. Wer baut das App-Skelett
Bei allen drei Alternativen ist die erste ehrliche Frage: Wer schreibt Login, Mandantentrennung, Rollenmodell und Audit-Log? Bei Next.js+Prisma und Rails ist die Antwort “Euer Team, mit Libraries als Hilfe”. Bei Supabase ist es “Euer Team, mit Diensten als Hilfe”. Bei Kumiko ist die Antwort “die KI unterstützt Euch per Chat interaktiv, Ihr editiert und besitzt den Code danach” (vollautomatische Generierung aus reinem Text: Kern-Feature ab H2 2026).
Das ist kein Qualitätsunterschied — ein erfahrenes Rails- oder Next.js-Team baut das genauso solide. Der Unterschied ist Zeit: bei Kumiko ist das Skelett am ersten Tag fertig, nicht in Woche drei.
2. Event-Sourcing vs. klassisches CRUD
Next.js+Prisma und Rails/ActiveRecord arbeiten klassisch CRUD-basiert: Ihr überschreibt Zeilen, ein Änderungsprotokoll ist ein Zusatzprojekt. Kumiko ist event-sourced: jede Schreiboperation ist ein unveränderliches Event, der aktuelle Stand ist eine Projektion davon. Das ist der Grund, warum Audit-Trail, Undo und Zeitreise bei Kumiko “eingebaut” statt “nachgerüstet” sind — aber es ist auch ein Paradigmenwechsel, den ein CRUD-erfahrenes Team erst lernen muss.
3. Ökosystem-Reife vs. Generierungs-Geschwindigkeit
Next.js, Rails und Supabase gewinnen klar bei “wie viele fertige Bausteine gibt es für mein Nischenproblem”. Wenn Ihr eine exotische Zahlungsanbindung, ein spezielles CMS oder eine Legacy-API anbinden müsst, findet Ihr in npm oder RubyGems fast immer schon etwas. Kumiko hat bewusst ein kleineres, kuratiertes Set an Bundled-Features (Auth, Notifications, Jobs, Files, Billing, GDPR-Compliance) statt eines offenen Marktplatzes — dafür ist der Weg von Idee zu laufender App radikal kürzer.
Wann Ihr Next.js+Prisma wählen solltet
Ehrlich:
- Ihr braucht maximale Architektur-Freiheit (eigenes Rendering, eigenes Datenmodell, kein Framework-Vertrag)
- Euer Team ist tief im React/TypeScript-Ökosystem zu Hause
- Ihr braucht eine exotische Integration, für die es bereits eine npm-Library gibt
- Zeit ist kein Engpass — Ihr könnt Wochen in das App-Skelett investieren
Wann Ihr Rails wählen solltet
- Euer Team kennt Ruby und schätzt Convention-over-Configuration
- Ihr baut ein klassisches CRUD-lastiges Produkt ohne komplexe Workflows
- Ihr wollt vom riesigen, ausgereiften Gem-Ökosystem profitieren
- Battle-Testing bei großer Skalierung ist ein hartes Kriterium (Shopify, GitHub laufen auf Rails)
Wann Ihr Supabase wählen solltet
- Ihr baut ein MVP oder Side-Project ohne Mandantentrennung
- Euer Team ist SQL-erfahren, Row-Level-Security ist kein Problem
- Mehr dazu im ausführlichen Supabase-Vergleich
Wann Ihr Kumiko wählen solltet
- Ihr wollt vom ersten Tag an eine B2B-SaaS mit mehreren Mandanten, nicht erst nachrüsten
- Änderungsprotokoll ist Compliance-Pflicht (ISO 27001, BaFin, DSGVO) und soll nicht handgebaut werden
- DACH/EU-Hosting ist Pflicht, nicht “später mal prüfen”
- Ihr wollt KI-gestützten, iterativen Backend-Aufbau und den generierten Code trotzdem in Eurem Repo behalten — keine Blackbox (volle Text-zu-Feature-Generierung: Kern-Feature ab H2 2026)
- Ihr akzeptiert eine Lernkurve beim Event-Sourcing-Paradigma gegen Wochen gesparte Boilerplate-Zeit
Was Kumiko (noch) nicht kann
Ehrlich, pre-1.0:
- Ökosystem: kein npm- oder RubyGems-großes Marktplatz an Integrationen — bundled Features statt tausender Community-Packages
- Architektur-Freiheit: Ihr arbeitet innerhalb des Kumiko-Datenmodells (Event-Sourcing, TypeScript, Bun) — kein beliebiger Sprach- oder Rendering-Stack
- Talent-Pool: Kumiko-Entwickler lernt Ihr im Team an, es gibt (noch) keinen Markt fertig ausgebildeter Kumiko-Engineers
- Battle-Testing: deutlich jünger als Rails oder Next.js — weniger Jahre an Produktions-Erfahrung im großen Maßstab
- Skalierungs-Referenzen: publicstatus.eu läuft produktiv, aber es gibt noch keine Referenz in der Größenordnung von Shopify oder GitHub
Belege, die Ihr intern weitergeben könnt
- Live-System:
publicstatus.euläuft bereits end-to-end auf Kumiko und zeigt Multi-Tenant-Betrieb produktiv, nicht nur in Slides. - Generierter Code bleibt Euer Code: Kumiko generiert TypeScript-Handler in Eurem Repo, kein proprietäres DSL, kein Vendor-Format — Ihr könnt jederzeit von Hand weiterarbeiten.
- Pricing-Pfad: Der Self-Host-Pfad startet mit Hosting + Plattformumfang statt Per-Seat-Abrechnung.
- FAQ / Einwände: Hosting, Lock-in, lokales LLM und Audit sind bereits auf der FAQ- und Pricing-Seite konkret beantwortet.
Wie ein realistischer Pilot mit Kumiko aussieht
- Use-Case prüfen: Ihr schickt Euer aktuelles Datenmodell oder Tool-Setup.
- Fit ehrlich klären: Wir sagen offen, ob Kumiko für Euren Fall passt oder ob Ihr besser bei Eurem bestehenden Stack bleibt.
- Pilot-Setup bauen: Ein erstes Feature läuft mit Eurem Hosting- und Rollenmodell.
- Entscheidung treffen: Danach ist klar, ob sich der Wechsel für Euer Team lohnt.
Migration von Next.js/Rails/Supabase nach Kumiko
Realistisch ein paar Tage bis wenige Wochen für ein typisches Schema, je nach Komplexität. Postgres bleibt bei allen drei Ausgangspunkten meist die Datenbank, die Ihr behalten könnt. Auth wird neu (Kumiko hat ein eigenes Auth-Bundle), Business-Logik wird zu Kumikos Event-Handlern portiert. Ein Migrations- und Fit-Check ist Teil des Pilot-Gesprächs.
Entscheidungsregel in einem Satz
Wählt Next.js+Prisma, Rails oder Supabase, wenn Euer Team den Stack schon beherrscht, Zeit für den Eigenbau hat und maximale architektonische Freiheit braucht.
Wählt Kumiko, wenn Ihr das App-Skelett (Mandanten, Rollen, Audit, Admin-UI) nicht mehr selbst bauen wollt, sondern generieren lassen — und trotzdem echten, editierbaren Code in Eurem Repo behalten wollt.
→ Pilot prüfen: [email protected]
Weiterlesen: