97 Prozent geteilter Code. Dreifache Produktivität.
Das sind die beiden Zahlen, mit denen die neue „Why Flutter“-Seite einsteigt. Sie sind stark. Aber die interessantere Frage ist für mich nicht, ob es am Ende exakt 97 Prozent sind.
Die eigentliche Frage lautet: Wie viele Grenzen muss ein Team noch überqueren, bevor eine Änderung beim Nutzer ankommt?
Flutter reduziert diese Grenzen zwischen iOS, Android, Web und Desktop. Serverpod führt denselben Gedanken im Backend weiter. Mit Serverpod 4 reicht die gemeinsame Schleife von der Oberfläche über Endpunkte und generierten Client-Code bis zur Datenbank.
Das ist der Teil, der für mich den Unterschied macht.
Starke Zahlen, mit einer wichtigen Fußnote
Im Flutter-Whitepaper 2026 schreibt Google, Flutter-Apps teilten im Durchschnitt 97 Prozent ihres Codes über mehrere Plattformen. Außerdem habe Google bei eigenen Teams, die Flutter einsetzen, wiederholt eine dreifache Produktivität gemessen.
Diese Werte sind Herstellerangaben. Das Whitepaper erklärt an dieser Stelle nicht, welche Projekte verglichen wurden, wie Produktivität gemessen wurde oder wie groß die Stichprobe war. Ich würde daraus deshalb keine Garantie für das nächste Projekt ableiten.
Die Richtung passt allerdings zu einer breiteren Beobachtung. Für den unabhängigen Flutter CTO Report befragte LeanCode knapp 300 CTOs, CIOs und Tech Leads. 56,4 Prozent berichteten von mindestens 50 Prozent höherer Entwicklungsgeschwindigkeit gegenüber nativer Entwicklung; mehr als 80 Prozent sahen mindestens 20 Prozent Verbesserung. Auch das sind Selbstauskünfte und keine kontrollierte Studie. Aber sie beschreiben denselben praktischen Effekt: Eine gemeinsame Codebasis spart nicht nur Schreibarbeit. Sie reduziert Abstimmung, doppelte Fehlerbehebung und versetzte Releases.
Der größte Gewinn steckt für mich deshalb nicht in einer einzelnen Kennzahl. Er steckt in weniger Übergaben.
Flutter verbindet die Plattformen
Mit Flutter baue ich eine Oberfläche, eine Fachlogik und einen großen Teil der Tests einmal. Plattformunterschiede verschwinden dadurch nicht. Berechtigungen, Push Notifications, Store-Prozesse oder native APIs bleiben reale Arbeit.
Aber sie werden zu gezielten Abweichungen statt zur Grundstruktur des Projekts.
Das verändert die tägliche Entwicklung. Eine fachliche Änderung muss nicht in zwei Teams erklärt, zweimal umgesetzt und anschließend zwischen iOS und Android synchronisiert werden. Hot Reload verkürzt zusätzlich die Schleife zwischen Änderung und sichtbarem Ergebnis.
Für ein kleines oder fokussiertes Team ist das wichtiger als die reine Zahl der geteilten Codezeilen. Das Team arbeitet an einem Produkt, nicht an mehreren technisch getrennten Varianten davon.
Serverpod führt die Schleife durch den Stack
Bei vielen Cross-Platform-Projekten endet die Vereinheitlichung am API-Rand. Die App ist Flutter und Dart. Dahinter beginnt ein anderer Stack mit einer anderen Sprache, anderen Modellen und eigenen Werkzeugen.
Das kann die richtige Architektur sein. Es ist aber wieder eine Grenze.
Serverpod 4 macht diese Grenze für Flutter-Projekte deutlich kleiner. App, Server und Datenmodelle verwenden Dart. Serverpod generiert typisierten Client-Code für Endpunkte, kümmert sich um Protokoll und ORM und bringt mit serverpod start die lokale Umgebung zusammen.
Der neue Full-Stack Hot Reload geht noch einen Schritt weiter: Ändert sich ein Datenmodell, werden Code und Datenbank aktualisiert. Ändert sich ein Endpoint, lädt der Server neu. Ändert sich die Flutter-Oberfläche, erscheint das Ergebnis direkt in der laufenden App. Die Quickstart-Dokumentation beschreibt denselben Ablauf inzwischen auch für KI-gestützte Editoren.
- 01 Flutter-App Eine Oberfläche für iOS, Android, Web und Desktop.
- 02 Generierter Client Typisierte Aufrufe statt handgeschriebener API-Brücken.
- 03 Serverpod-Backend Endpunkte, Fachlogik, Authentifizierung und Jobs in Dart.
- 04 PostgreSQL Modelle, Relationen und Migrationen im selben Workflow.
Das ist mehr als „überall dieselbe Sprache“. Entscheidend ist, dass eine Änderung nicht an jeder Schicht in einen neuen manuellen Prozess fällt.
Warum das mit KI noch wichtiger wird
KI kann Code schnell schreiben. Geschwindigkeit allein macht ein System aber nicht zuverlässig.
Ein Agent braucht Kontext, einen kurzen Feedback-Zyklus und überprüfbare Ergebnisse. Serverpod 4 liefert dafür Skills und einen MCP-Server mit Zugriff auf die laufende Entwicklungsumgebung und ihre Logs. Der Agent kann Änderungen nicht nur erzeugen, sondern ihren Effekt im zusammenhängenden Stack sehen.
Das nimmt mir die Prüfung nicht ab. Generierte Modelle, Migrationen, Zugriffsregeln und Fehlerfälle bleiben meine Verantwortung. Aber es verkürzt den Weg zwischen einer Entscheidung und dem Moment, in dem ich sie im laufenden Produkt prüfen kann.
Genau dort entsteht produktive KI-Entwicklung: nicht durch möglichst viel generierten Code, sondern durch möglichst wenig Reibung zwischen Änderung, Ausführung und Review.
Würde ich diesen Stack immer wählen?
Nein.
Eine stark plattformspezifische App kann mit nativer Entwicklung besser bedient sein. Eine textlastige Website mit hohen SEO-Anforderungen gehört nicht automatisch in Flutter. Und für ein kleines Backend mit wenigen Endpunkten kann ein leichteres Framework völlig ausreichen.
Auch eine gemeinsame Sprache schützt nicht vor schlechter Architektur. Wenn App, Fachlogik und Persistenz unkontrolliert ineinanderlaufen, wird aus weniger Grenzen schnell mehr Kopplung. Die Schichten müssen weiterhin klare Aufgaben haben.
Für Produkt-Apps, die mehrere Plattformen erreichen sollen und von einem kleinen bis mittleren Team gebaut werden, ist die Kombination trotzdem außergewöhnlich schlüssig: Flutter vereinheitlicht die Plattformen. Serverpod vereinheitlicht die Entwicklungsschleife dahinter.
97 Prozent geteilter Code sind eine gute Schlagzeile. Für mich ist der wertvollere Effekt ein anderer: Eine Produktidee muss auf ihrem Weg zum Nutzer seltener übersetzt werden.