TL;DR: Next.js+Prisma, Ruby on Rails, and Supabase are three different but equally proven ways to build your own backend — with a massive ecosystem, plenty of docs, and developers you can actually hire. If your team already knows one of these stacks and has the time to wire up multi-tenancy, an audit trail, and role management by hand, that’s a solid path. With Kumiko, you build it iteratively via AI chat — and you still get real, editable code in your own repo, not a black box. Full text-to-feature generation is a core feature landing H2 2026.
Who this comparison is for
This comparison is written for engineering leads and CTOs currently making a stack decision for a new internal tool, portal, or B2B SaaS product:
- Teams weighing “we build it ourselves on a proven framework” against “we let it get generated”
- Projects that need multi-tenancy, role management, an audit trail, or GDPR compliance from day one
- Teams that already have a Next.js, Rails, or Supabase background and want to know what they’d be trading for Kumiko
If your team is already deep into one of the three stacks, that stack works for you, and you have no reason to switch — “stick with your stack” is often the right answer. This comparison is for the moment you’re deciding fresh.
What the three alternatives are
Next.js + Prisma: Probably the most common TypeScript stack for web apps today. Next.js for routing, rendering, and API routes; Prisma as a type-safe ORM over Postgres/MySQL/SQLite. A massive npm ecosystem, and React-team skills are everywhere. You build auth, multi-tenant scoping, an audit trail, and admin UI yourself — usually with additional libraries (NextAuth, your own middleware) or by hand.
Ruby on Rails: A batteries-included framework since 2004, MVC, ActiveRecord as ORM. Convention-over-configuration means a lot ships ready to use (migrations, background jobs via Sidekiq, mailers), but multi-tenancy, fine-grained roles, and a complete audit log are still your job — usually via gems like pundit, paper_trail, or acts_as_tenant.
Supabase: Backend-as-a-service on top of Postgres — auth, realtime, storage, and edge functions as services. You write SQL and row-level-security policies; Supabase hosts it. A separate in-depth comparison is available.
All three are mature, proven paths with huge communities. The difference to Kumiko isn’t quality — it’s who builds what: with all three, you build the app skeleton (tenants, roles, audit, admin UI) yourself; with Kumiko, you build it with AI-chat assistance, and you still keep the full, editable code (fully automatic generation from plain text is a core feature landing H2 2026).
Where they’re stronger
Honestly:
- Ecosystem size: npm has well over 2 million packages, RubyGems tens of thousands of mature gems. For almost any niche problem, a library probably already exists
- Talent pool: you’ll find Next.js and Rails developers on every job board. Kumiko developers you train up in-house — the learning curve is real
- Maturity and battle-testing: Rails has run in production for over 20 years at Shopify, GitHub, Basecamp. Next.js powers a large share of the modern web. Kumiko is considerably younger
- Architectural freedom: you can pick any data model, any library, any rendering approach — no framework contract locking you onto one path
- Mobile and third-party integrations: for exotic connections (payment providers, CRMs, legacy systems), both ecosystems almost always already have a ready-made library
That matters because Kumiko doesn’t have to win when your team already knows the stack, has time for the build, and needs maximum architectural freedom. That’s exactly where Next.js+Prisma and Rails are strong.
Where Kumiko is stronger
| Aspect | Next.js + Prisma | Rails | Supabase | Kumiko |
|---|---|---|---|---|
| Time to running app | Weeks — build auth, tenant scoping, audit, admin UI yourself | Days to weeks — more ships ready, but tenants/audit are still manual | DB is up in minutes, everything else (auth wiring, RLS, frontend, audit) is on you | Under 2 minutes from click to live URL — auth, multi-tenant, audit, realtime, admin UI included |
| Backend generation | You write every route, every model | You write every model, every controller | You write SQL + RLS policies | AI chat patches/extends features interactively, you edit the code (full text-to-feature generation landing H2 2026) |
| Multi-tenant separation | Build it yourself (middleware, row scoping) | Build it yourself (gem like acts_as_tenant) | Build it yourself (RLS policies per table) | Built in — every entity is tenant-scoped |
| Audit trail | Build it yourself | Gem like paper_trail | Build it yourself (triggers or your own table) | Built in — every write is an event |
| Roles / access control | Build it yourself or a library (e.g. CASL) | Gem like pundit/cancancan | RLS policies per table | Declarative per handler, feature-toggle and tier-aware |
| Background jobs with audit trail | Library (BullMQ etc.), logging yourself | Sidekiq, logging yourself | Edge functions, logging yourself | Built in incl. operator UI + run log |
| Live schema changes | Deploy required | Deploy required | Deploy required | Designer edit → users see it in seconds, no reload |
| DACH/EU hosting | Any host (your choice) | Any host (your choice) | EU region possible | Hetzner / on-prem / bare-metal default |
| Lock-in | Low — standard stack, code in your repo | Low — standard stack, code in your repo | Medium (OSS, but the hosting stack is large) | Low — generated code in your repo, framework public under BSL (→ Apache-2.0 after 2 years) |
| Ecosystem size | Huge (npm) | Large (RubyGems) | Large | Small — bundled features instead of a marketplace |
The decision-relevant differences in practice
1. Who builds the app skeleton
With all three alternatives, the first honest question is: who writes auth, multi-tenant separation, role management, and the audit log? For Next.js+Prisma and Rails, the answer is “your team, with libraries as help.” For Supabase, it’s “your team, with services as help.” For Kumiko, the answer is “AI assists you interactively via chat, you edit and own the code afterward” (fully automatic generation from plain text: core feature landing H2 2026).
That’s not a quality difference — an experienced Rails or Next.js team builds it just as solidly. The difference is time: with Kumiko, the skeleton is done on day one, not in week three.
2. Event sourcing vs. classic CRUD
Next.js+Prisma and Rails/ActiveRecord work classically CRUD-based: you overwrite rows, an audit trail is an add-on project. Kumiko is event-sourced: every write is an immutable event, current state is a projection of it. That’s why audit trail, undo, and time-travel are “built in” rather than “bolted on” in Kumiko — but it’s also a paradigm shift a CRUD-experienced team has to learn first.
3. Ecosystem maturity vs. generation speed
Next.js, Rails, and Supabase clearly win on “how many ready-made building blocks exist for my niche problem.” If you need an exotic payment integration, a specific CMS, or a legacy API connection, npm or RubyGems almost always already has something. Kumiko deliberately has a smaller, curated set of bundled features (auth, notifications, jobs, files, billing, GDPR compliance) instead of an open marketplace — in exchange, the path from idea to running app is radically shorter.
When you should choose Next.js+Prisma
Honestly:
- You need maximum architectural freedom (custom rendering, custom data model, no framework contract)
- Your team is deeply at home in the React/TypeScript ecosystem
- You need an exotic integration that already has an npm library
- Time isn’t a constraint — you can invest weeks in the app skeleton
When you should choose Rails
- Your team knows Ruby and values convention-over-configuration
- You’re building a classic, CRUD-heavy product without complex workflows
- You want to benefit from the huge, mature gem ecosystem
- Battle-testing at large scale is a hard requirement (Shopify, GitHub run on Rails)
When you should choose Supabase
- You’re building an MVP or side project without multi-tenant separation
- Your team is SQL-experienced, row-level security isn’t a problem
- More in the in-depth Supabase comparison
When you should choose Kumiko
- You want a B2B SaaS with multiple tenants from day one, not bolted on later
- An audit trail is a compliance requirement (ISO 27001, SOC 2, GDPR) and shouldn’t be hand-built
- DACH/EU hosting is a hard requirement, not “check later”
- You want AI-assisted, iterative backend building and still want to keep the generated code in your own repo — no black box (full text-to-feature generation: core feature landing H2 2026)
- You accept a learning curve on the event-sourcing paradigm in exchange for weeks of saved boilerplate time
What Kumiko can’t (yet) do
Honestly, pre-1.0:
- Ecosystem: no npm- or RubyGems-sized marketplace of integrations — bundled features instead of thousands of community packages
- Architectural freedom: you work within Kumiko’s data model (event sourcing, TypeScript, Bun) — not an arbitrary language or rendering stack
- Talent pool: you train Kumiko developers in-house, there’s (yet) no market of pre-trained Kumiko engineers
- Battle-testing: considerably younger than Rails or Next.js — fewer years of large-scale production experience
- Scale references: publicstatus.eu runs in production, but there’s no reference yet at the scale of Shopify or GitHub
Evidence you can share internally
- Live system:
publicstatus.eualready runs end-to-end on Kumiko and shows multi-tenant operation in production, not just in slides. - Generated code stays your code: Kumiko generates TypeScript handlers in your repo, no proprietary DSL, no vendor format — you can always keep working by hand.
- Pricing path: the self-host path starts with hosting + platform scope, not per-seat billing.
- FAQ / objections: hosting, lock-in, local LLM, and audit are already answered concretely on the FAQ and pricing pages.
What a realistic pilot with Kumiko looks like
- Check the use case: you send your current data model or tool setup.
- Clarify fit honestly: we tell you openly whether Kumiko fits your case or whether you’re better off sticking with your existing stack.
- Build a pilot setup: a first feature runs with your hosting and role model.
- Make the decision: after that, it’s clear whether switching is worth it for your team.
Migrating from Next.js/Rails/Supabase to Kumiko
Realistically a few days to a few weeks for a typical schema, depending on complexity. Postgres usually stays the database you keep across all three starting points. Auth gets rebuilt (Kumiko has its own auth bundle), business logic gets ported to Kumiko’s event handlers. A migration and fit check is part of the pilot conversation.
The one-sentence decision rule
Choose Next.js+Prisma, Rails, or Supabase if your team already knows the stack, has time for the build, and needs maximum architectural freedom.
Choose Kumiko if you no longer want to build the app skeleton (tenants, roles, audit, admin UI) yourself — you want it generated — while still keeping real, editable code in your own repo.
→ Check a pilot: [email protected]
Keep reading: