Das richtige Web Framework wählen: warum ich Next.js und Ruby on Rails nutze, und wann die anderen besser passen

Die kurze Antwort: das Framework folgt der Aufgabe

Ich arbeite vor allem mit zwei Frameworks. Mit Next.js für die Seiten, die Menschen lesen und durchklicken, und mit Ruby on Rails für die Anwendung dahinter, in der die Geschäftsregeln stecken. Bei Shops baut diese Rails Anwendung auf Solidus auf, einer Open Source eCommerce Engine für Rails.

Ich nutze die beiden nicht, weil sie gerade in Mode sind. Ich nutze sie, weil ich damit schnell vorankomme, sicher bleibe und gleichzeitig ein flexibles Frontend und ein robustes Backend bekomme. Das ist meine Wahl für meine Arbeit. Ein Naturgesetz ist es nicht, und gute Teams bauen jeden Tag gute Produkte mit Laravel, Django, Express, NestJS und WordPress.

Deshalb erkläre ich hier, was jedes dieser Frameworks ist, vergleiche sie an den Stellen, an denen ein Unternehmen Geld verliert oder spart (Passung, Menschen, Supportzeiträume, Lizenz), und gehe mit einem erfundenen Münchner Unternehmen eine Entscheidung Schritt für Schritt durch. Die technischen Fakten stammen aus der offiziellen Dokumentation, abgerufen am 8. November 2026. Die Unternehmen und Zahlen in den Beispielen sind erfunden.

Was ein Web Framework eigentlich macht

Ein Web Framework ist ein fertiges Gerüst für eine Webanwendung. Wenn ein Browser eine Seite anfragt, muss etwas den Code finden, der zu dieser Adresse gehört (Routing), die Daten holen, die Regeln anwenden und das Ergebnis in HTML verwandeln. Ein Framework erledigt die wiederkehrenden Teile jedes Mal gleich, damit die Entwicklerin oder der Entwickler nur das schreibt, was dein Geschäft besonders macht.

Frameworks unterscheiden sich darin, wie viel sie dir abnehmen. Rails beschreibt sich selbst als meinungsstark: Es "has opinions about the best way to do many things in a web application" und zieht Konventionen den Konfigurationsdateien vor.¹ Express steht am anderen Ende und nennt sich "fast, unopinionated, minimalist".² Keins davon ist an sich besser. Ein meinungsstarkes Framework gibt dir einen ausgetretenen Pfad. Ein minimales gibt dir Freiheit, und mit ihr jede einzelne Entscheidung.

Beispiel: eine Bestellseite, Schritt für Schritt

Ein Beispiel: Eine Kundin eines Hamburger Blumenladens öffnet https://blumenundzweige.example/orders/481. Dabei passieren fünf Dinge.

1. Der Router liest die Adresse und findet den Code, der eine Bestellung anzeigt, mit 481 als Bestellnummer.
2. Dieser Code fragt die Datenbank nach Bestellung 481.
3. Eine Regel prüft, ob die anfragende Person auch die Kundin ist, die bestellt hat.
4. Ein Template macht aus der Bestellung HTML: den Strauß, den Liefertermin, den Preis.
5. Der Server schickt die Seite zurück.

In einem meinungsstarken Framework folgen die Schritte eins, zwei und vier Konventionen, also schreibt man hauptsächlich Schritt drei. In einem minimalen sucht man sich zuerst einen Router, eine Datenbankbibliothek und eine Template Engine aus.

Next.js: React auf dem Server, für die Seiten, die Menschen lesen

Next.js ist ein Framework auf Basis von React, der JavaScript Bibliothek für Benutzeroberflächen. Sein App Router ist der Standard für neue Projekte.³

Die wichtigste Idee ist die Server Component. Im App Router sind Layouts und Seiten standardmäßig Server Components. Sie holen die Daten und rendern auf dem Server und schicken fertiges HTML an den Browser.⁴ React definiert Server Components als Komponenten, die vorab rendern, entweder einmal beim Build oder bei jeder Anfrage.⁵ Nur die Teile, die im Browser interaktiv sein müssen, etwa ein Button mit Zustand, werden zu Client Components und tragen "use client" am Anfang der Datei.⁴ So landet weniger JavaScript auf dem Handy deiner Besucher.

Wann wird eine Seite gerendert? Next.js kennt drei Antworten, und eine Seite darf sie mischen.

• Beim Build vorgerendert. Die Seite entsteht einmal und wird als Datei ausgeliefert, der schnellste Fall überhaupt.
• Im Hintergrund neu erzeugt. Incremental Static Regeneration (ISR) liefert eine vorgerenderte Seite aus und baut sie nach einer festgelegten Zeit oder auf Anforderung neu, sodass sich Inhalte ändern, ohne dass die ganze Website neu gebaut wird.⁶
• Bei jeder Anfrage gerendert, für alles, was von der Besucherin abhängt, etwa von einem Cookie.

Mit eingeschalteten Cache Components, die neue Apps mit den empfohlenen Standardeinstellungen bereits haben, baut Next.js für jede Route eine statische Hülle und streamt die Teile, die frisch sein müssen, zur Anfragezeit hinein. Die Dokumentation nennt das Partial Prerendering.⁷ Die Direktive use cache markiert Daten oder Komponenten zum Cachen, mit einer Lebensdauer, die cacheLife festlegt.⁷

Vercel, das Unternehmen hinter Next.js, brauchst du dafür nicht. Next.js läuft als Node.js Server, in Docker oder als statischer Export, und Cache Components und ISR funktionieren auch selbst gehostet, ISR allerdings nicht beim statischen Export.⁶⁸

Warum ich es nutze: für alles, was Kundinnen und Kunden sehen und wo Tempo, Reaktionsfähigkeit und Feinschliff zählen. Zusammen mit einem robusten Backend, etwa Rails oder einer Headless eCommerce Engine, deckt es den Teil des Produkts ab, den die Kundschaft tatsächlich zu Gesicht bekommt.

Beispiel: eine Studiowebsite mit drei Arten von Seiten

Ein Beispiel: Alster Pilates ist ein erfundenes Studio in Hamburg. Seine Website unter alsterpilates.example hat drei Arten von Seiten.

Startseite und Über uns ändern sich zweimal im Jahr. Sie werden beim Build vorgerendert, jede Besucherin bekommt dieselbe Datei.

Der Kursplan ändert sich im Laufe des Tages. Angenommen, 2.000 Menschen am Tag öffnen ihn. Für jede einzeln frisch gerendert, sind das 2.000 Renderings. Mit einer Lebensdauer von einer Stunde gecacht, wird er höchstens 24 Mal am Tag gerendert:

$v = \frac{V}{R} = \frac{2.000}{24} \approx 83$

Dabei ist $v$ die Zahl der Besucher, die sich ein Rendering teilen, $V$ die Zahl der Besucher pro Tag und $R$ die höchste Zahl an Renderings pro Tag, die eine Lebensdauer von einer Stunde zulässt. Grundlagen: Verhältnisse und Raten

// app/timetable/page.tsx
import { cacheLife } from 'next/cache'

export default async function Timetable() {
  'use cache'
  cacheLife('hours')
  const classes = await fetch('https://api.alsterpilates.example/classes').then((r) => r.json())
  return <ClassList classes={classes} />
}

Die Begrüßung für Mitglieder ("Willkommen zurück, Jo") liest ein Cookie und lässt sich deshalb nicht teilen. Sie sitzt in einer Suspense Grenze und wird zur Anfragezeit hineingestreamt, während der Rest der Seite aus der statischen Hülle kommt.⁷

Ruby on Rails: eine Anwendung, die die Geschäftsregeln hält

Rails ist ein Full Stack Framework für Ruby, gebaut um zwei Ideen, die es selbst nennt: Don't Repeat Yourself und Convention Over Configuration.¹ Eine einzige Anwendung enthält die Modelle, die Regeln, die Hintergrundarbeit, die Mails und die Adminoberflächen, und zwar in jedem Rails Projekt gleich angeordnet.

Rails 8, erschienen im November 2024, hat dafür gesorgt, dass diese eine Anwendung weniger fremde Dienste braucht.⁹ Die Ankündigung zählt die neuen Standards auf:

• Solid Queue führt Hintergrundjobs auf der Datenbank aus, die du ohnehin hast. Weder Redis noch ein eigenes Jobframework sind nötig.⁹
• Solid Cache legt gecachte Seitenfragmente auf der Festplatte ab statt in Redis oder Memcached.⁹
• Solid Cable leitet WebSocket Nachrichten über die Datenbank.⁹
• Kamal 2 ist fertig eingerichtet, um auf einen Cloud Server oder eigene Hardware zu deployen, mit Thruster vor dem Applikationsserver, sodass kein Nginx nötig ist.⁹ Kamal deployt jede App, die in einem Container läuft, nicht nur Rails.¹⁰
• Ein Generator für die Authentifizierung legt die Grundmodelle für Nutzer und Sitzungen an.⁹

Die aktuelle Versionslinie ist 8.1.¹¹

Darauf sitzt Solidus. Seine Guides beschreiben es als freie Open Source eCommerce Plattform auf Basis von Ruby on Rails, gebaut als Rails Engine.¹² Eine Engine steckt man in die eigene Anwendung, also teilen sich Katalog, Warenkorb, Checkout und Bestellungen eine Codebasis mit deinen eigenen Regeln. Mehr dazu in Headless Solidus.

Warum ich es nutze: Damit liefere ich robuste Systeme schnell. In Wachstumsprojekten zählt, wie schnell etwas Wert bringt, mehr als jeder Trend. In Rails lege ich SaaS Backends, Adminbereiche und Abläufe, bei denen die Geschäftslogik wichtiger ist als pixelgenaue Oberflächen.

Beispiel: Verlängerungen für einen Teeclub im Abo

Ein Beispiel: Der Teeclub Plagwitz ist ein erfundenes Leipziger Unternehmen mit 1.200 Abonnentinnen und Abonnenten, deren Abo sich jeweils am Ersten des Monats verlängert. Jede Verlängerung heißt: Karte belasten und eine Bestätigungsmail schicken. Angenommen, jede dauert zwei Sekunden, vor allem weil auf den Zahlungsanbieter und den Maildienst gewartet wird.

Nacheinander erledigt, sind das $1.200 \times 2 = 2.400$ Sekunden, also 40 Minuten. Deshalb wird jede Verlängerung ein Hintergrundjob in Solid Queue. Mit vier Jobs gleichzeitig dauert der ganze Stapel $2.400 \div 4 = 600$ Sekunden, zehn Minuten, und niemand wartet auf eine Seite. In Rails 8 braucht das keinen zusätzlichen Server: Die Jobs sind Zeilen in derselben Datenbank wie die Abos.⁹

Warum ich die beiden kombiniere

Next.js rendert die Seiten, die die Kundschaft sieht. Rails hält die Daten und die Regeln. Dazwischen setze ich eine REST oder GraphQL API und teste diese Grenze sorgfältig, wie ich in TDD und BDD für APIs erkläre.

Lies das Diagramm von oben: Jeder Kasten ist ein Schritt eines einzigen Besuchs, in der richtigen Reihenfolge. Die obere Hälfte ist Next.js, das die Seite auf den Bildschirm bringt. Die untere Hälfte ist Rails, das entscheidet, welcher Preis heute für genau diese Kundin gilt. Die API in der Mitte ist der Vertrag zwischen beiden.

Die Kombination hat ihren Preis: zwei Anwendungen, die deployt und aktualisiert werden wollen, statt einer. Für ein kleines Produkt mit wenig öffentlicher Website reicht oft eine einzige Rails Anwendung mit eigenen Views. Die Kombination lohnt sich, wenn die öffentlichen Seiten in Suche und Kampagnen echtes Gewicht tragen.

Beispiel: wo eine Preisänderung ankommt

Ein Beispiel: Ein Kölner Großhändler für Bäckereiware ändert den Händlerpreis für Sauerteigbrote von 2,40 € auf 2,55 €. Die Änderung passiert einmal, im Rails Admin. Die Produktseite in Next.js zeigt sie bei der nächsten Anfrage, denn der Preis ist ein aktueller Teil, der über die API abgefragt wird, während Fotos und Beschreibung weiter aus der statischen Hülle kommen. Eine einzige Quelle der Wahrheit, und kein Neubau der Website für 15 Cent.

Die fairen Alternativen

Jede dieser Optionen ist in den richtigen Händen eine gute Wahl. Hier steht, was jede ist, nach ihrer eigenen Dokumentation, und wann ich sie empfehlen würde.

Laravel

Laravel ist ein Full Stack Framework für PHP, mit eigenen Queues, eigenem Caching, Starter Kits für die Authentifizierung und mehr. Einmal im Jahr erscheint eine Hauptversion, ungefähr im ersten Quartal. Laravel 13 erschien am 17. März 2026 und braucht mindestens PHP 8.3.¹³ Für mich ist es das Rails der PHP Welt, und das meine ich als Kompliment. Für Teams, die schon in PHP arbeiten, oder für Unternehmen mit PHP Betreuung im Haus ist Laravel eine sehr gute Wahl. Ich bevorzuge Rails einfach wegen seiner Konsistenz und seiner Kultur.

Django

Django ist ein Full Stack Framework für Python. Seine Adminoberfläche entsteht aus deinen Datenmodellen und ist als internes Verwaltungswerkzeug für vertrauenswürdige Mitarbeitende gedacht, nicht als öffentliches Frontend.¹⁴ Die Dokumentation beschreibt die Schutzmechanismen, die gleich mitkommen: Templates maskieren riskante Zeichen und verhindern so den Großteil von Cross Site Scripting, Querysets sind gegen SQL Injection geschützt, und es gibt eingebauten Schutz gegen Cross Site Request Forgery und Clickjacking.¹⁵ Ich setze Django für Data Science Anwendungen mit viel Python Logik ein, bei denen die Analysepipeline wichtiger ist als die Darstellung. Für APIs ziehe ich trotzdem Rails vor, und für Projekte mit viel Oberfläche Next.js.

Express, und NestJS obendrauf

Express ist das kleine, flexible Web Framework für Node.js, "fast, unopinionated, minimalist".² NestJS ergänzt die Struktur, die Express weglässt: Es ist ein Framework für serverseitige Node.js Anwendungen, nutzt standardmäßig Express darunter, kann stattdessen Fastify verwenden und übernimmt seine Architektur stark von Angular.¹⁶ Express nehme ich, wenn ich Microservices oder kleine API Endpunkte am Rand eines Systems baue. Bei größeren Apps wird es zu einem Knäuel aus Entscheidungen ohne Leitplanken. NestJS bringt für genau dieses Problem eigene Konventionen mit.

WordPress

WordPress ist kein Framework, sondern ein Content Management System, und für eine Website, die vor allem aus Artikeln und Seiten besteht, die Leute ohne Programmierkenntnisse pflegen, ist es oft die ehrliche Antwort. Es steht unter der GPLv2 oder später.¹⁷ Schwieriger wird es, wenn eine Website eigene Geschäftsregeln entwickelt, die dann in Plugins und Themes leben. Darüber habe ich einen eigenen Artikel zu WordPress und PHP geschrieben.

Beispiel: drei Teams, drei richtige Antworten

Ein Beispiel: drei erfundene Unternehmen, drei Antworten.

Eine Münchner Personalvermittlung hat zwei PHP Entwickler, die ihre Systeme in und auswendig kennen. Sie braucht ein Kundenportal. Laravel, weil die Leute, die es pflegen werden, die Sprache schon sprechen.

Ein Leipziger Startup für Datenanalyse erstellt Prognosen in Python und zeigt sie in einem Dashboard für Kunden. Django, weil die Modelle und die Website dann eine Sprache und eine Codebasis teilen.

Eine Hamburger Eventfirma betreibt eine kleine Buchungs API, die ihre Partner aufrufen, und daneben eine eigene Website. Express oder NestJS für die API, weil die Aufgabe aus einer Handvoll Endpunkten besteht, nicht aus einer ganzen Anwendung.

Keiner dieser Fälle ist mein Stack, und jeder ist für dieses Team richtig.

Wie lange jede Version gepflegt wird

Jedes Framework hört irgendwann auf, alte Versionen zu reparieren. Endet der Sicherheitssupport, bleibt eine neu entdeckte Lücke offen, solange du nicht aktualisierst. Damit sind Upgrades bei jeder Wahl laufende Kosten.

• Rails: Jede Minor Serie bekommt ein Jahr lang Bugfixes und zwei Jahre lang Sicherheitsfixes, gerechnet ab ihrem ersten Release. Rails 8.1 hat Sicherheitssupport bis zum 10. Oktober 2027. Der Sicherheitssupport für Rails 8.0 endete am 7. November 2026.¹¹
• Next.js: Eine Hauptversion ist im Active LTS, bis die nächste Hauptversion erscheint, danach im Maintenance LTS, mit nur noch kritischen Bugfixes und Sicherheitsupdates, bis zwei Jahre nach ihrem ersten Release. Next.js 16 erschien am 21. Oktober 2025. Next.js 15 bekommt Sicherheitsreleases bis zum 31. Januar 2027, eine Verlängerung des ursprünglichen Datums. Wartungsreleases können als Minor Versionen erscheinen, auch wenn sie inkompatible Änderungen enthalten.¹⁸
• Laravel: Bugfixes für 18 Monate und Sicherheitsfixes für zwei Jahre. Laravel 12 hat Sicherheitsfixes bis zum 24. Februar 2027, Laravel 13 bis zum 17. März 2028.¹³
• Django: 5.2 ist die aktuelle Version mit Langzeitsupport (LTS), unterstützt bis April 2028. Django 6.1 wird bis Dezember 2027 unterstützt, und die nächste LTS Version, 6.2, ist für April 2027 geplant.¹⁹
• Express: Unterstützt wird nur die jeweils neueste Version jeder Hauptlinie. Die Versionen 4 und 5 stehen beide ohne Enddatum als unterstützt in der Liste.²⁰

Die waagrechte Achse zeigt die neueste Versionslinie jedes Frameworks, dazu die LTS Version von Django. Die senkrechte Achse zeigt die Monate von November 2026 bis zum veröffentlichten Ende des Sicherheitssupports. Die Erkenntnis: Bei keinem davon kannst du bauen und vergessen. Jede Option hier braucht innerhalb von etwa anderthalb Jahren ein Upgrade.

Beispiel: ein Upgradekalender

Ein Beispiel: Ein Leipziger Händler für Gartenbedarf betreibt seinen Shop auf Rails 8.0 und seine Marketingwebsite auf Next.js 15. Heute ist der 8. November 2026.

Rails 8.0 hat gestern, am 7. November 2026, den Sicherheitssupport verloren.¹¹ Dieses Upgrade ist also überfällig.

Next.js 15 bekommt Sicherheitsreleases bis zum 31. Januar 2027.¹⁸ Ab dem 8. November bleiben 22 Tage im November, 31 im Dezember und 31 im Januar: $22 + 31 + 31 = 84$ Tage, also 12 Wochen.

Also: Rails 8.0 auf 8.1 noch in diesem Monat, danach Next.js 15 auf 16 innerhalb von 12 Wochen, beides als bekannte Kosten eingeplant.

Was die Lizenz dir erlaubt

Rails, Next.js, Laravel, Express und NestJS stehen unter der MIT Lizenz.^2122232425 Django und Solidus stehen unter der BSD 3 Clause Lizenz.²⁶²⁷ Beide sind freizügig: Du darfst Software, die damit gebaut ist, nutzen, ändern und verkaufen, auch als Closed Source, solange du den Urheberrechtshinweis und den Lizenztext beibehältst. Die BSD 3 Clause Variante ergänzt, dass du die Namen des Projekts und seiner Mitwirkenden nicht ohne Erlaubnis nutzen darfst, um für dein Produkt zu werben.²⁶

WordPress steht unter der GPLv2 oder später, einer Copyleft Lizenz. Die eigene Position von WordPress ist, dass abgeleitete Werke die GPL erben und dass Plugins und Themes abgeleitete Werke sind. Gleichzeitig räumt WordPress eine gewisse rechtliche Grauzone ein.¹⁷

Für eine Website, die du für dich selbst baust, ändert das selten etwas. Wichtig wird es, wenn du das Gebaute verkaufen oder weitergeben willst, und dann fragst du am besten eine Anwältin oder einen Anwalt.

Beispiel: das Buchungsmodul verkaufen

Ein Beispiel: Eine Kölner Kletterhalle will ihr eigenes Buchungsmodul unter einer geschlossenen Lizenz an andere Hallen verkaufen.

Ist das Modul ein WordPress Plugin, erbt es nach der Position von WordPress die GPL,¹⁷ also braucht eine geschlossene Lizenz vor dem Start rechtliche Beratung. Ist es eine Rails Engine, verlangt die MIT Lizenz nur, dass der Hinweis von Rails mit Rails selbst mitreist,²¹ und die Halle kann ihren eigenen Code lizenzieren, wie sie will.

Beliebtheit, einmal gemessen und datiert

Beliebtheit zählt aus einem praktischen Grund: wie viele Menschen an deinem System arbeiten können. Der Stack Overflow Developer Survey 2025 hat gefragt, mit welchen Web Frameworks und Technologien die Befragten im vergangenen Jahr intensiv entwickelt haben, und 23.678 Befragte haben diese Frage beantwortet.²⁸

Die waagrechte Achse zeigt die Frameworks aus diesem Artikel. Die senkrechte Achse zeigt den Anteil aller Befragten dieser Frage, die im vergangenen Jahr intensiv mit dem jeweiligen Framework gearbeitet haben. Mehrfachnennungen waren möglich, deshalb ergeben die Anteile zusammen nicht 100 %. Die Erkenntnis: Die JavaScript Optionen haben die größten Pools an Leuten, Rails den kleinsten der sieben. Gezählt sind Entwicklerinnen und Entwickler weltweit, die freiwillig geantwortet haben, nicht der deutsche Markt, und die Zahl sagt, wie groß der Pool ist, nicht welches Framework besser ist.

Beispiel: der Pool pro tausend

Ein Beispiel: Stell dir 1.000 dieser Befragten vor.

$N = q \times 1.000$

Dabei ist $N$ die erwartete Zahl der 1.000 Befragten, die mit einem Framework arbeiten, und $q$ der Umfrageanteil dieses Frameworks als Dezimalzahl. Grundlagen: Verhältnisse und Raten

Next.js: $0{,}208 \times 1.000 = 208$. Laravel: $0{,}089 \times 1.000 = 89$. Rails: $0{,}059 \times 1.000 = 59$. Auf jede Rails Entwicklerin in der Stichprobe kommen also etwa $208 \div 59 = 3{,}5$ Leute mit Next.js und $89 \div 59 = 1{,}5$ mit Laravel. Für ein Unternehmen, das einstellen muss, fließt das in die Bewertung weiter unten ein.

Beispiel: eine Münchner Kaffeerösterei wählt ihren Stack

Die Rösterei Giesing ist eine erfundene Kaffeerösterei in München. Sam, die Inhaberin, braucht drei Dinge: eine Marketingwebsite mit Blog, einen Onlineshop mit Kaffeeabos und ein Bestellportal für den Großhandel, in dem Cafés ihre eigenen Preise sehen und auf Rechnung bestellen. Im Haus gibt es niemanden, der programmiert. Jede Zahl unten ist eine Annahme für dieses Beispiel, kein Angebot.

Drei Optionen liegen auf dem Tisch.

• A: WordPress mit WooCommerce, die Großhandelsregeln in Plugins.
• B: eine Laravel Anwendung, der Shop aus Paketen und eigenem Code zusammengebaut.
• C: Rails mit Solidus für Shop und Portal, dazu eine Marketingwebsite in Next.js.

Schritt eins: die Gesamtkosten über fünf Jahre

Die Gesamtkosten (Total Cost of Ownership) addieren den Bau, die laufenden Kosten, die Kosten für Änderungen und die erwarteten Kosten, wenn etwas schiefgeht:

$TC = C_0 + T\,(12m + k\,c) + \sum_i p_i\,x_i$

Dabei ist $TC$ die Summe der Kosten über den Zeitraum, $C_0$ die einmaligen Baukosten, $T$ der Zeitraum in Jahren, $m$ die monatlichen Kosten für Hosting, Lizenzen und Pflege, $k$ die Zahl der Änderungen pro Jahr, $c$ die Kosten einer Änderung, und $\sum_i p_i\,x_i$ die erwarteten Kosten der Risiken, also für jedes Risiko seine Wahrscheinlichkeit $p_i$ mal seine Kosten $x_i$. Grundlagen: Erwartungswert

Die Annahmen, mit Begründung. $T = 5$ Jahre und $k = 8$ Änderungen pro Jahr für jede Option. A kostet im Bau 14.000 €, weil der Großteil des Shops als Plugins schon existiert, und 350 € im Monat inklusive Pluginlizenzen. Jede Änderung kostet 900 €, weil sich die Großhandelsregeln um Plugins von Dritten herum fügen müssen, die Sam nicht kontrolliert. Aus demselben Grund trägt A eine Chance von eins zu vier auf eine Nacharbeit für 10.000 €. B und C schreiben die Großhandelsregeln als ganz normalen Anwendungscode: 600 € pro Änderung und eine Chance von eins zu zehn, dass ein Upgrade um 6.000 € teurer wird als geplant. B kostet im Bau 32.000 €, weil der Shop aus Einzelteilen entsteht, und 250 € im Monat für eine Anwendung. C kostet 30.000 €, weil Solidus den Shop mitbringt, und 300 € im Monat für zwei Anwendungen.

Option A:

$TC_A = 14.000 + 5\,(12 \times 350 + 8 \times 900) + 0{,}25 \times 10.000$

$12 \times 350 = 4.200$ und $8 \times 900 = 7.200$, zusammen $11.400$ pro Jahr. Fünf Jahre ergeben $57.000$. Das Risiko liegt bei $2.500$. Also $TC_A = 14.000 + 57.000 + 2.500 = 73.500$ €. Grundlagen: Erwartungswert

Option B:

$TC_B = 32.000 + 5\,(12 \times 250 + 8 \times 600) + 0{,}10 \times 6.000$

$12 \times 250 = 3.000$ und $8 \times 600 = 4.800$, zusammen $7.800$ pro Jahr und $39.000$ über fünf Jahre. Das Risiko liegt bei $600$. Also $TC_B = 32.000 + 39.000 + 600 = 71.600$ €. Grundlagen: Erwartungswert

Option C:

$TC_C = 30.000 + 5\,(12 \times 300 + 8 \times 600) + 0{,}10 \times 6.000$

$12 \times 300 = 3.600$ und $4.800$ für Änderungen, zusammen $8.400$ pro Jahr und $42.000$ über fünf Jahre. Das Risiko liegt bei $600$. Also $TC_C = 30.000 + 42.000 + 600 = 72.600$ €. Grundlagen: Erwartungswert

Die waagrechte Achse zeigt die drei Optionen, die senkrechte die Gesamtkosten über fünf Jahre in Euro. Die Erkenntnis ist, wie nah sie beieinanderliegen: 1.900 € zwischen der teuersten und der günstigsten, etwa 2,7 % der niedrigsten Summe. Unter diesen Annahmen entscheiden die Kosten allein nichts.

Schritt zwei: eine gewichtete Bewertung

Wenn die Kosten so nah beieinanderliegen, hängt die Wahl an Dingen, die kein Geld sind. Eine gewichtete Bewertung stellt sie nebeneinander:

$S_j = \sum_{i=1}^{n} w_i\, s_{ij}$

Dabei ist $S_j$ die Gesamtpunktzahl von Option $j$, $n$ die Zahl der Kriterien, $w_i$ das Gewicht von Kriterium $i$, wobei alle Gewichte zusammen eins ergeben, und $s_{ij}$ die Punktzahl von eins bis fünf, die Option $j$ bei Kriterium $i$ bekommt. Die Formel hat dieselbe Form wie ein Erwartungswert, nur mit Gewichten statt Wahrscheinlichkeiten. Grundlagen: Erwartungswert

Sam legt vier Kriterien und ihre Gewichte fest:

• Passung für die Großhandelsregeln, Gewicht 0,35. A bekommt 2, B 4, C 5, weil der Shop bei C schon in derselben Rails Codebasis steckt, in der die Regeln geschrieben werden.
• Kosten über fünf Jahre, Gewicht 0,25. Die niedrigste Summe bekommt 5, und für jede 1.000 € darüber geht ein halber Punkt ab. B bekommt 5. C liegt 1.000 € darüber, also 4,5. A liegt 1.900 € darüber, also $5 - 0{,}95 = 4{,}05$.
• Menschen, die es pflegen können, Gewicht 0,25. Nach den Umfragepools oben bekommt A 4, B 4, C 3.
• Tempo und Bearbeitung der Marketingseiten, Gewicht 0,15. A bekommt 4, weil die Redaktion WordPress kennt, B 3, C 5, wegen der vorgerenderten statischen Hülle.

Option A: $0{,}35 \times 2 + 0{,}25 \times 4{,}05 + 0{,}25 \times 4 + 0{,}15 \times 4 = 0{,}70 + 1{,}01 + 1{,}00 + 0{,}60 = 3{,}31$.

Option B: $0{,}35 \times 4 + 0{,}25 \times 5 + 0{,}25 \times 4 + 0{,}15 \times 3 = 1{,}40 + 1{,}25 + 1{,}00 + 0{,}45 = 4{,}10$.

Option C: $0{,}35 \times 5 + 0{,}25 \times 4{,}5 + 0{,}25 \times 3 + 0{,}15 \times 5 = 1{,}75 + 1{,}13 + 0{,}75 + 0{,}75 = 4{,}38$.

C gewinnt mit 0,28 Punkten Vorsprung. A, mit den niedrigsten Baukosten, landet auf dem letzten Platz, weil das Großhandelsportal der schwierige Teil dieser Aufgabe ist.

Schritt drei: eine Tatsache ändern, und die Antwort kippt

Jetzt angenommen, Sam hat einen PHP Entwickler, der schon lange im Haus ist. Die Personalwertung von B steigt auf 5, die von C fällt auf 2, weil der Entwickler erst Ruby lernen müsste. Sonst ändert sich nichts.

Option B: $1{,}40 + 1{,}25 + 0{,}25 \times 5 + 0{,}45 = 1{,}40 + 1{,}25 + 1{,}25 + 0{,}45 = 4{,}35$.

Option C: $1{,}75 + 1{,}13 + 0{,}25 \times 2 + 0{,}75 = 1{,}75 + 1{,}13 + 0{,}50 + 0{,}75 = 4{,}13$.

Jetzt gewinnt Laravel mit 0,22 Punkten Vorsprung. Das ist die Lehre in einer einzigen Rechnung: Das Framework ist selten die entscheidende Tatsache. Das Team, der schwierige Teil der Aufgabe und die Kosten von Änderungen sind es.

Ein Entscheidungsablauf zum Mitnehmen

Beantworte die Fragen von oben nach unten. Ein Ja führt zum jeweiligen Vorschlag, ein Nein zur nächsten Frage. Jeder Weg endet gleich: mit der Rechnung der Gesamtkosten und dem Upgradekalender, denn ein Stack, den du dir nicht leisten kannst aktuell zu halten, ist der falsche Stack.

Was das für dich heißt

Ich halte nichts von Frameworks, die nur vom Hype leben. Jedes Unternehmen hat seine eigenen Rahmenbedingungen: die Erfahrung des Teams, die Zeit bis zum Marktstart, die Wartbarkeit, die Flexibilität und die Kosten. Ich baue mit Rails und Next.js, weil ich damit diese Rahmenbedingungen besser im Griff habe als mit jeder anderen Kombination, die ich bisher gefunden habe.

Trotzdem: Gute Ergebnisse kommen nicht von Frameworks. Sie kommen davon, wie man sie einsetzt. Wähl den Stack, der zu deinem Team und deinem schwierigsten Problem passt, rechne ihn über fünf Jahre durch und trag die Upgradetermine gleich am ersten Tag in den Kalender ein.

Footnotes

1. Ruby on Rails, Getting Started with Rails, Rails Guides v8.1.4.1, guides.rubyonrails.org, abgerufen am 8. November 2026, https://guides.rubyonrails.org/getting_started.html

2. Express, Express: fast, unopinionated, minimalist web framework for Node.js, expressjs.com, abgerufen am 8. November 2026, https://expressjs.com/

3. Vercel, Installation, Next.js Dokumentation, nextjs.org, aktualisiert am 2. Oktober 2026, https://nextjs.org/docs/app/getting-started/installation

4. Vercel, Server and Client Components, Next.js Dokumentation, nextjs.org, aktualisiert am 5. Oktober 2026, https://nextjs.org/docs/app/getting-started/server-and-client-components

5. React, Server Components, react.dev, abgerufen am 8. November 2026, https://react.dev/reference/rsc/server-components

6. Vercel, How to implement Incremental Static Regeneration (ISR), Next.js Dokumentation, nextjs.org, aktualisiert am 15. Oktober 2026, https://nextjs.org/docs/app/guides/incremental-static-regeneration

7. Vercel, Caching (Cache Components and Partial Prerendering), Next.js Dokumentation, nextjs.org, aktualisiert am 6. Oktober 2026, https://nextjs.org/docs/app/getting-started/caching

8. Vercel, How to self host your Next.js application, Next.js Dokumentation, nextjs.org, aktualisiert am 15. Oktober 2026, https://nextjs.org/docs/app/guides/self-hosting

9. David Heinemeier Hansson, Rails 8.0: No PaaS Required, rubyonrails.org, 7. November 2024, https://rubyonrails.org/2024/11/7/rails-8-no-paas-required

10. Kamal, Deploy web apps anywhere, kamal-deploy.org, abgerufen am 8. November 2026, https://kamal-deploy.org/

11. Ruby on Rails, Maintenance policy for Ruby on Rails, rubyonrails.org, abgerufen am 8. November 2026, https://rubyonrails.org/maintenance

12. Solidus, Introduction, Solidus Guides, guides.solidus.io, abgerufen am 8. November 2026, https://guides.solidus.io/

13. Laravel, Release notes, Laravel 13.x Dokumentation, laravel.com, abgerufen am 8. November 2026, https://laravel.com/docs/13.x/releases

14. Django Software Foundation, The Django admin site, Django Dokumentation, docs.djangoproject.com, abgerufen am 8. November 2026, https://docs.djangoproject.com/en/stable/ref/contrib/admin/

15. Django Software Foundation, Security in Django, Django Dokumentation, docs.djangoproject.com, abgerufen am 8. November 2026, https://docs.djangoproject.com/en/stable/topics/security/

16. NestJS, Introduction, NestJS Dokumentation, docs.nestjs.com, abgerufen am 8. November 2026, https://docs.nestjs.com/

17. WordPress, License, wordpress.org, abgerufen am 8. November 2026, https://wordpress.org/about/license/

18. Vercel, Next.js support policy, nextjs.org, abgerufen am 8. November 2026, https://nextjs.org/support-policy

19. Django Software Foundation, Download: supported versions and roadmap, djangoproject.com, abgerufen am 8. November 2026, https://www.djangoproject.com/download/

20. Express, Version support, expressjs.com, abgerufen am 8. November 2026, https://expressjs.com/en/support/

21. Ruby on Rails, MIT Lizenzdatei, GitHub, abgerufen am 8. November 2026, https://raw.githubusercontent.com/rails/rails/main/MIT-LICENSE

22. Vercel, Next.js Lizenzdatei (MIT), GitHub, abgerufen am 8. November 2026, https://raw.githubusercontent.com/vercel/next.js/canary/license.md

23. Laravel, Lizenzdatei des Laravel Frameworks (MIT), GitHub, abgerufen am 8. November 2026, https://raw.githubusercontent.com/laravel/framework/12.x/LICENSE.md

24. Express, Express Lizenzdatei (MIT), GitHub, abgerufen am 8. November 2026, https://raw.githubusercontent.com/expressjs/express/master/LICENSE

25. NestJS, Nest Lizenzdatei (MIT), GitHub, abgerufen am 8. November 2026, https://raw.githubusercontent.com/nestjs/nest/master/LICENSE

26. Django Software Foundation, Django Lizenzdatei (BSD 3 Clause), GitHub, abgerufen am 8. November 2026, https://raw.githubusercontent.com/django/django/main/LICENSE

27. Solidus contributors, Solidus Lizenzdatei (BSD 3 Clause), GitHub, abgerufen am 8. November 2026, https://raw.githubusercontent.com/solidusio/solidus/main/LICENSE

28. Stack Overflow, 2025 Developer Survey: Technology, web frameworks and technologies, survey.stackoverflow.co, 2025, https://survey.stackoverflow.co/2025/technology