Das Framework, über das niemand mehr redet
Niemand twittert mehr begeistert über Rails. Keine atemlosen Blogposts. Keine Konferenz-Keynotes, in denen verkündet wird: “Wir schreiben alles in Ruby um.”
Genau darum geht es.
Rails ist das Framework, das Sie wählen, wenn Sie lieber Features ausliefern als über Architektur diskutieren. Und im B2B-SaaS-Bereich ist das Ausliefern von Features das gesamte Spiel.
Wir haben SaaS-Plattformen, interne Tools und kundenorientierte Anwendungen seit Jahren auf Rails gebaut. Wir haben auch mit Node.js, Python und Go gearbeitet. Wir kommen immer wieder zu Rails zurück. Nicht aus Loyalität. Aus Geschwindigkeit.
Das hier ist kein Liebesbrief. Es ist ein praktisches Argument dafür, warum Convention-over-Configuration immer noch gewinnt, wenn Sie Software bauen, die Geld verdienen soll.
Shopify hat diese Debatte längst entschieden
Wenn jemand fragt, ob Rails skaliert: Die Antwort ist ein Unternehmen, das an einem einzigen Black-Friday-Wochenende 14,6 Milliarden Dollar Händlerumsatz verarbeitet hat. Shopifys Rails-Monolith bewältigte 489 Millionen Anfragen pro Minute in der Spitze. Die Codebasis: 2,8 Millionen Zeilen Ruby, gepflegt von über 3.100 Ingenieurinnen und Ingenieuren.
Das ist kein Spielzeug-Framework. Das ist Infrastruktur, die einen Teil des globalen Handels antreibt.
GitHub läuft auf Rails. Ebenso Basecamp, HEY und Stripes Kern-Abrechnungssysteme. Über 667.000 Unternehmen weltweit nutzen Rails. Das Framework stirbt nicht. Es ist nur langweilig. Langweilig ist genau das, was Sie unter Ihrem Umsatz haben wollen.
Lago, eine Open-Source-Abrechnungsplattform, die täglich Millionen von API-Aufrufen verarbeitet, hat kürzlich darüber geschrieben. Ihr Fazit: “Skalierung ist ein Architektur- und Betriebsproblem, keine Framework-Limitierung.” Sie nutzen Go für I/O-intensive Services und Rust für CPU-intensive Aufgaben, aber das Kernprodukt bleibt auf Rails, weil ihr Team damit am schnellsten ausliefert.
Was bei B2B-SaaS wirklich zählt
B2B-SaaS ist zu 90 % CRUD. Benutzer erstellen Datensätze, aktualisieren sie, durchsuchen Listen, erstellen Berichte. Es gibt ein Dashboard. Es gibt Rollen und Berechtigungen. Es gibt eine Billing-Integration. Vielleicht ein paar Webhooks.
Nichts davon ist schwer. Alles davon kostet Zeit.
Rails komprimiert diese Zeit. Active Record kümmert sich um Ihre Datenschicht. Action Mailer verschickt transaktionale E-Mails.
Active Job verarbeitet Hintergrundaufgaben.
Devise verwaltet Authentifizierung. Pundit regelt Autorisierung. Stripe-rails kapselt Abrechnung.
Ein Entwickler auf Rails kann das bauen, wofür ein typischer TypeScript-Stack ein dreiköpfiges Team braucht: separater API-Server, separate Frontend-App, separater Worker-Prozess, drei verschiedene Deployment-Pipelines, drei Sätze von Abhängigkeiten zum Pflegen.
Klingt übertrieben? Wir haben es erlebt. Ein Kunde kam zu uns, nachdem er vier Monate damit verbracht hatte, ein Next.js-Frontend mit einem NestJS-Backend für ein im Grunde mandantenfähiges Rechnungstool zu bauen. Vier Monate. Login und ein einzelnes Formular funktionierten. Wir haben den gleichen Umfang in Rails in sechs Wochen neu gebaut, inklusive Stripe-Abrechnung, rollenbasiertem Zugriff und einem Mandanten-Onboarding-Flow.
Der Unterschied lag nicht am Talent. Das Team war fähig. Der Unterschied war die Meinung des Frameworks darüber, wie Anwendungen funktionieren sollten.
Rails 8 hat das Deployment-Problem gelöst
Die größte berechtigte Kritik an Rails war immer das Deployment. Heroku machte es einfach, aber teuer. AWS machte es mächtig, aber komplex.
Docker half, erforderte aber weiterhin Orchestrierungs-Know-how.
Rails 8 hat das mit Kamal 2 gelöst. Ein Befehl: kamal setup. Richten Sie es auf einen frischen Linux-Server, und es kümmert sich um Docker, SSL via Let’s Encrypt, Zero-Downtime-Deploys und Health-Checks. Ihr 20-€/Monat-Hetzner-VPS wird in unter zwei Minuten zur Produktionsumgebung.
Das ist kein Scherz. HEY (das E-Mail-Produkt von 37signals mit Hunderttausenden Nutzern) läuft auf diesem Stack.
Rails 8 lieferte auch die Solid-Trifecta. Drei datenbankgestützte Adapter, die Redis für die meisten Anwendungen komplett ersetzen:
Solid Queue verarbeitet 20 Millionen Jobs pro Tag bei HEY. Kein Redis. Kein Sidekiq. Nur Ihre bestehende PostgreSQL-Datenbank für Ihre Hintergrundaufgaben.
Solid Cache speichert 10 Terabyte gecachte Daten bei Basecamp. Die P95-Renderzeiten wurden halbiert. Wieder: kein Redis nötig.
Solid Cable wickelt WebSocket-Verbindungen über die Datenbank ab. Echtzeit-Features, ohne ein weiteres Infrastrukturteil hinzuzufügen.
Für ein B2B-SaaS-Startup bedeutet das: Sie können Ihre gesamte Anwendung (Webserver, Hintergrundaufgaben, Caching, WebSockets) auf einem einzigen Server mit einer einzigen Datenbank betreiben. Ihre monatliche Infrastrukturrechnung: etwa 40 €. Versuchen Sie das mal mit einem Next.js + Redis + BullMQ + separatem WebSocket-Server-Setup.
Ruby ist schnell geworden, ohne dass jemand hingeschaut hat
Ruby war langsam. Das ist echte Geschichte, kein Mythos. Aber es ist veraltete Geschichte.
YJIT, Shopifys Just-in-Time-Compiler, der mit Ruby ausgeliefert wird, ist mittlerweile 92 % schneller als der Standard-Interpreter auf Produktions-Benchmarks. Reale Rails-Anwendungen sehen 15-25 % Geschwindigkeitsverbesserungen mit aktiviertem YJIT. CPU-intensive Workloads gewinnen über 40 %.
Ruby 4.0 (veröffentlicht im Dezember 2025) ging noch weiter. Es führte ZJIT ein, einen Compiler der nächsten Generation, der den Interpreter bereits schlägt und YJIT langfristig überholen soll. Das Ruby-Core-Team hat Performance zur obersten Priorität gemacht, unterstützt durch Shopifys Engineering-Ressourcen.
Ist Ruby so schnell wie Go oder Rust? Nein. Wird es nie sein. Spielt das eine Rolle für Ihr B2B-SaaS mit 500 gleichzeitigen Nutzern? Nicht im Entferntesten. Ihr Engpass ist die Datenbank, nicht die Sprach-Runtime. Das ist immer so.
Wann wir Rails nicht wählen
Wir sind meinungsstark, aber nicht dogmatisch. Rails ist nicht die Antwort auf alles.
Wenn Sie ein Echtzeit-Kollaborationstool bauen (denken Sie an Figma oder Miro), brauchen Sie etwas, das WebSocket-Verbindungen im großen Maßstab handhabt. Go oder Elixir passt für diese spezifische Schicht besser.
Wenn Ihre Anwendung primär eine Single-Page-App mit komplexem clientseitigem State ist (Drag-and-Drop-Editoren, Canvas-basierte Tools), macht React mit einem schlanken API-Backend mehr Sinn. Rails kann diese API sein, aber Sie nutzen dann das meiste nicht, was Rails produktiv macht.
Wenn Ihr Team kein Ruby kann. Das zählt mehr als jedes technische Argument. Ein Python-Team, das mit Django ausliefert, schlägt ein Team, das Rails erst lernt. Immer.
Das beste Framework ist das, in dem Ihre Leute denken können.
Wenn Sie schnell 50 Entwickler einstellen müssen. Der JavaScript-Talentpool ist größer. Punkt. Für ein Startup, das seine ersten drei oder vier Ingenieure einstellt, spielt das keine Rolle, denn Rails-Entwickler gibt es in jeder größeren Stadt. Für ein Scale-up, das eine 50-köpfige Engineering-Organisation aufbaut, kann es relevant werden.
Das “Zurück zu Rails”-Muster
Wir sind nicht die Einzigen, die das bemerken. Hardcover, eine Buch-Tracking-Plattform, hat kürzlich einen detaillierten Bericht über die Migration von Next.js zurück zu Rails mit Inertia.js veröffentlicht. Ihre Gründe: unklares Caching in Next.js, steigende Infrastrukturkosten und langsamere Entwicklungsgeschwindigkeit bei wachsender Anwendung.
Sie behielten React für das Frontend, verlagerten aber das gesamte Backend auf Rails. Ladezeiten verbesserten sich. Google PageSpeed-Scores stiegen. Die Entwicklungsgeschwindigkeit nahm zu.
Dieses Muster taucht überall auf. Das Pendel schwang um 2020 hart in Richtung JavaScript-für-alles. Jetzt schwingt es zurück. Nicht weil JavaScript schlecht ist, sondern weil viele Teams feststellten, dass sie eine Komplexitätssteuer zahlten, die ihnen nichts einbrachte.
42 % der Organisationen, die Microservices eingeführt haben, konsolidieren zurück zu einfacheren Architekturen. Die Branche lernt, was Rails-Entwickler seit 20 Jahren wissen: Die meisten Anwendungen sind als gut strukturierter Monolith besser aufgehoben.
Unser Stack im Detail
Für B2B-SaaS-Projekte setzen wir typischerweise ein:
Ruby on Rails 8 mit PostgreSQL. Hotwire (Turbo + Stimulus) für interaktive Oberflächen ohne separates Frontend. Tailwind CSS für das Styling.
Solid Queue für Hintergrundaufgaben. Kamal für das Deployment auf Hetzner Cloud oder Ihr bevorzugtes EU-Rechenzentrum.
Gesamte Infrastrukturkosten für ein SaaS in der Frühphase: 40-80 € pro Monat. Zeit vom Projektstart bis zum funktionierenden MVP: 6-10 Wochen, je nach Umfang.
Wenn Kunden ein reichhaltigeres Frontend brauchen (komplexe Dashboards, intensive Interaktivität), kombinieren wir Rails als API mit React oder Vue über Inertia.js. Sie bekommen Rails’ Backend-Produktivität mit einem modernen komponentenbasierten Frontend. Keine separate API-Schicht. Keine CORS-Probleme. Kein dupliziertes Routing.
Der ganze Sinn ist, Ihr Produkt auszuliefern, nicht Infrastruktur zu bauen. Rails ermöglicht es einem kleinen Team, über seiner Gewichtsklasse zu kämpfen. Für B2B-SaaS ist das die einzige Metrik, die zählt.
Für einen breiteren Blick auf unsere Technologie-Entscheidungen lesen Sie unser Tech-Stack-Entscheidungsframework. Und wenn Sie abwägen, ob Eigenentwicklung oder Standardsoftware der richtige Weg ist, führt unser Entscheidungsframework durch die echten Zahlen.
Sie bauen ein B2B-SaaS-Produkt und fragen sich, welcher Stack der richtige ist? Lassen Sie uns darüber sprechen. Wir schauen uns Ihre Anforderungen, Ihr Team und Ihren Zeitplan an und geben Ihnen eine ehrliche Empfehlung.
