Rewrite eines FinTech-Consulting-Tools: Web, Windows und macOS aus einer Flutter-CodebaseFinton-Rewrite mit Flutter

Was macht Finton und warum ist das Tool so zentral?

Finton berät Finanzabteilungen und liefert dazu einen eigenen Tool-Stack, heute mit Schwerpunkt auf KI-Lösungen für das Office of the CFO im Mittelstand. Service plus Software: Genau dieses Modell wird gerade in einer Geschwindigkeit baubar, die vorher nicht möglich war. Was vor wenigen Jahren ein Plattform-Build über 18 Monate gewesen wäre, ist heute ein Production-Tool in 6 Monaten. Das ist der eigentliche Hintergrund des Mandats. Nicht „wir bauen ein Tool“, sondern „wir bauen die Auslieferungsschicht einer Beratung der nächsten Generation“.

Das alte Tool war ein gewachsener Prototyp: Lags im Kern-Workflow, technische Schulden, und das Team konnte keine weiteren Kunden annehmen, ohne dass die Codebase zum Engpass wurde. Mit dieser Ausgangslage kam Finton zu mir. Was sie konkret brauchten:

• Datenvisualisierung auf einem Niveau, für das Kunden bereit sind zu zahlen. Schick, nicht „funktional ausreichend“
• Komplexe Datenanalysen direkt im Frontend, ohne ständigen Roundtrip zum Backend
• Flüssige Bedienung ohne Ruckeln, auch bei größeren Datenmengen im Dashboard
• Eine aufgeräumte Clean Architecture mit Feature-first-Ordnerstruktur (den klarsten Artikel dazu hat Code with Andrea geschrieben)
• Eine KI-Funktion, mit der Nutzer Dashboards selbst bauen können

Rewrite oder Refactor: was hat bei Finton gewonnen?

Die Mischung aus beidem. Am Ende wurde alles ersetzt, aber inkrementell. Die App musste an jedem Arbeitstag im Kundengeschäft funktionieren, eine Schreibtisch-Phase von 6 Monaten war nicht drin.

Konkret haben wir in den ersten 2 Monaten Tempo verloren: parallele Strukturen, viel Glue-Code, manchmal beide Implementierungen nebeneinander. Das war eingeplanter Schmerz, kein Unfall. In den letzten 4 Monaten hat es sich massiv ausgezahlt. Die Feature-Geschwindigkeit zog deutlich an, weil das Fundament getragen hat.

Wann diese Mischung der richtige Weg ist:

• Das Tool ist schon in Produktion
• Nutzer hängen dran, der Workflow läuft täglich darüber
• Funktionsfähigkeit ist nicht verhandelbar
• Es gibt genug Zeit für Fundamentarbeit, mindestens 4 bis 6 Monate

Wann nicht: Wenn niemand das Tool ernsthaft nutzt, ist ein klassischer Rewrite schneller. Und wenn das Team jede Woche nur Feature-Output liefern muss, garantiert die Mischung Frust in den ersten Monaten.

Welche Architektur-Entscheidung hat sich am meisten ausgezahlt?

Modularität. Wenn ich pro Mandat nur eine Architektur-Entscheidung hervorheben dürfte, wäre es diese. Bei Finton war sie der Hebel, der später alles möglich gemacht hat.

Ein Beispiel: Der Formular-Editor wurde von Anfang an als eigener Baustein gebaut. Er deckt drei Anwendungsfälle ab:

• Eingabe von Mandantendaten
• KPI-Definition durch die Consultants
• Eigene Felder im Dashboard

Drei Anwendungsfälle, ein Editor. In einer monolithisch gewachsenen Architektur wäre er dreimal geschrieben, dreimal gewartet worden und dreimal auseinandergelaufen.

Auch das Dashboard war vom ersten Tag an modular gedacht. Was daraus folgte, hat am Anfang niemand vorhergesehen:

1. Die modulare Struktur erlaubt es, Dashboards als JSON zu serialisieren.
2. Mit JSON-Dashboards können Nutzer neue Dashboards selbst erstellen.
3. Mit JSON-Dashboards kann auch die KI Dashboards erzeugen.
4. Generierte JSONs werden in der App geprüft und ohne Umweg übernommen.

Ohne diese Modularität wäre die KI-Dashboard-Funktion ein Projekt von 6 Wochen geworden. Mit ihr war es eine Woche, weil das Format schon stand und die Renderer-Pipeline JSON schon verarbeiten konnte.

Modularität klingt nach Architektur-Lehrbuch. In der Praxis ist sie ein Zinseszins-Effekt: Jede Stunde, die du am Anfang in saubere Bausteine steckst, sparst du in den Monaten danach mehrfach wieder ein.

Riverpod oder Bloc?

In fast allen Fällen reicht Riverpod, und es ist die schnellste Variante. Eine eigene Bloc-artige Struktur lohnt sich nur, wenn du Gründe hast, die kein Standard-Setup mit Riverpod abdeckt. Diese Gründe habe ich selten gesehen.

Wichtiger als die Wahl des State-Managers ist, dass Riverpod richtig ausgeschöpft wird und nicht nur als „Stream im Provider“ dient: feingranulare Provider, abgeleitete States als eigene Provider statt Berechnungen im Widget, klare Abhängigkeitsketten. Wer Riverpod als reines Stream-Werkzeug nutzt, hätte sich die Bibliothek sparen können.

Der eigentliche Hebel ist die Clean Architecture, nicht das Werkzeug darunter. Riverpod ist mächtig, aber ohne saubere Schichtung wird auch daraus nur schnelleres Spaghetti.

Wann wird Clean Architecture zum Selbstzweck? Wenn du Schichten und Interfaces einführst, die niemand liest und niemand braucht. Meine Heuristik: Macht es Spaß, den Code zu lesen? Findest du, was du suchst, allein über Ordner- und Dateinamen? Steckt darin, was du erwartet hast? Wenn ja, stimmt die Dosierung. Wenn nicht, hast du zu viel oder zu wenig Struktur. Beides zeigt dieselben Symptome.

Warum sollte Code aussehen wie ein Inhaltsverzeichnis?

Weil Code-Struktur heute auch UX für KI-Agenten ist. Sieht dein Repo aus wie das Inhaltsverzeichnis eines Buches, findet ein Agent in Sekunden die richtige Datei. Ist es eine Schlange aus 200 Dateien ohne klare Hierarchie, halluziniert er Pfade und schreibt an der falschen Stelle.

Deshalb Feature-first statt Layer-first: lib/features/dashboards/, lib/features/forms/, lib/features/kpi/ statt lib/widgets/, lib/services/, lib/models/. Den maßgeblichen Artikel dazu im Flutter-Ökosystem hat Code with Andrea geschrieben.

Das Argument für CTOs: Feature-first kostet einmal eine Umstellung im Kopf. Es zahlt sich an jedem Tag aus, an dem ein Entwickler oder ein KI-Agent etwas Neues baut. Heute ist das jeder Arbeitstag.

Wo kippen KI-Funktionen in internen Tools?

An drei Stellen: bei den Token-Kosten, bei einer fehlenden Prüfschleife und bei einer Architektur, die nicht für KI gebaut ist. Dazu kommt die Frage, ob sich das Feature überhaupt rechnet.

Token-Kosten kippen zuerst

In der Demo läuft der Cloud-Aufruf mit dem teuersten Modell, in Produktion fressen genau diese Aufrufe die Marge. Die Hebel:

• Caching dort, wo Ergebnisse stabil sind
• Kleinere Modelle für Teilaufgaben ohne echtes Reasoning
• Lokale oder Offline-KI für einfache Klassifikation und Extraktion
• Ein hartes Token-Budget pro Feature statt „lass laufen“

Faustregel: Jeder KI-Aufruf kostet im schlimmsten Fall das Hundertfache des geplanten Betrags, wenn ein Nutzer ihn missbraucht oder ein Sonderfall zuschlägt. Das ist kein Argument gegen KI, sondern eine Vorgabe für die Architektur, mit der du planen musst.

Nicht-deterministische Features brauchen eine Prüfschleife

Bei Finton baut die KI Dashboards. Ein Dashboard ist eine JSON-Struktur, die der Renderer kennt. Falsches JSON sprengt das Tool nicht, es wird abgewiesen. Der Ablauf:

1. Die KI erzeugt JSON.
2. Das JSON wird gegen das Schema des internen Formats geprüft.
3. Ist es ungültig, geht der Fehler mit Rückmeldung an die KI zurück, und sie versucht es erneut.
4. Nach zwei Fehlversuchen bricht der Ablauf mit einer klaren Meldung ab: „Das hat nicht geklappt, formuliere deine Anfrage anders.“

Die Schleife mit Abbruch ist der Unterschied zwischen einem KI-Feature für die Demo und einem, das das Vertrauen der Nutzer nicht zerstört. Ohne Abbruch entstehen Endlosschleifen und explodierende Token-Kosten. Ohne saubere Rückmeldung fühlt sich das Feature wie ein Glücksspiel an.

Wann rechnet sich KI im internen Tool?

Mit einer nüchternen Kostenrechnung:

• Wie viele Stunden pro Woche spart das Feature dem Team?
• Was kostet eine dieser Stunden intern?
• Was kostet das Feature pro Monat an Tokens, Wartung und Behandlung von Sonderfällen?

Liegt die monatliche Ersparnis grob beim Dreifachen der KI-Kosten, lohnt sich das Feature. Darunter ist es Eitelkeit. Realistisch lohnt es sich meistens später, als man am Anfang glaubt. Plane das ein, statt dich später zu wundern.

Von KI erzeugte Oberflächen brauchen eine passende Architektur

Soll die KI später Teile der Oberfläche erzeugen, muss jeder betroffene Bereich als JSON serialisierbar sein. Das geht nur mit modularer Architektur vom ersten Tag an. Wer drei Monate in eine monolithische Form-Engine steckt und dann nachschiebt „die KI soll Formulare bauen können“, schreibt die Form-Engine neu. Bei Finton war das Dashboard von Anfang an als JSON-Struktur angelegt. Genau deshalb war die KI-Dashboard-Funktion ein Projekt von einer Woche und nicht von sechs.

„AI-First“ ist als Begriff abgenutzt. Praktisch heißt er: Jede Komponente, die du baust, sollte serialisierbar, prüfbar und durch ein Schema beschrieben sein. Dann sind von KI erzeugte Oberflächen eine Erweiterung der bestehenden Renderer und kein neues Projekt.

Ist Flutter die richtige Wahl für interne Tools?

Ja, für interne Tools ist Flutter ein No-Brainer. Eine Codebase, drei Plattformen in Produktion: Web, Windows und macOS. Genau das brauchen interne Tools, weil das Beratungsteam auf ganz unterschiedlichen Geräten arbeitet und niemand drei Frontend-Teams finanzieren will.

Was in Flutter eine Codebase leistet, wofür es mit React und React Native zwei Spezialisten gebraucht hätte:

• Pixelgenaue Datenvisualisierung, auf allen drei Plattformen identisch
• Flüssiges Scrollen in großen Tabellen ohne plattformspezifische Hacks
• Automatische Updates auf dem Desktop ohne eigenes Installer-Team

Wo Flutter im Moment schwächelt:

• Web-SEO bleibt eine Baustelle. Für interne Tools egal, für Marketing-Seiten ein Ausschlusskriterium
• Nativer iOS-Look auf Premium-Niveau verlangt Detailarbeit, die in SwiftUI günstiger ist
• WebViews und aufwendiges natives Einbetten sind weiterhin umständlicher als nötig

Für interne Tools spielt nichts davon eine Rolle.

Warum werden interne Tools unter Last langsam?

Meistens an drei Stellen: zu großer State, Listen ohne Lazy Loading und fehlendes Caching. Bei Finton war Performance kein theoretisches Problem: komplexe Berechnungen, viele Zeilen im Dashboard, alles im Frontend.

1. Zu großer State, der bei jeder kleinen Änderung halbe Bildschirme neu rendert
2. Listen ohne Lazy Loading, die ab 1.000 Zeilen pro Scroll einen Frame verlieren
3. Fehlendes Caching dort, wo es hingehört. Dieselben Finanzdaten werden dreimal nachgeladen, jedes Mal mit Spinner

Die Antwort darauf ist keine Magie, sondern Disziplin und ein Profiler:

• State-Reduktion auf dem kritischen Pfad, feingranulare Riverpod-Provider
• Lazy Loading nicht sichtbarer Module, damit ein Dashboard mit 12 Widgets nicht 12 API-Aufrufe abfeuert
• Caching wiederkehrender Finanzdaten an den richtigen Stellen, gemessen statt geraten

Wenn dein Tool ruckelt und niemand im Team den Profiler bedienen kann, ist das nicht in erster Linie ein Architektur-Problem. Es ist ein Senioritätsproblem im Team.

Wie entsteht gute UX ohne eigenes UX-Team?

Mit Erfahrung, die in Skills verdichtet ist. In einem Mandat wie Finton entsteht die Oberfläche im laufenden Betrieb: kein mitgeliefertes UX-Team, keine vierwöchige Workshop-Phase. Ich arbeite mit einem UX-Skill, der auf die Klassiker zugreift:

• Don Norman, The Design of Everyday Things (Signifier, Affordances, mentale Modelle)
• Steve Krug, Don’t Make Me Think (kognitive Last, Selbsterklärung)
• Susan Weinschenk, 100 Things Every Designer Needs to Know About People (Grenzen der Wahrnehmung, Aufmerksamkeit)
• Nir Eyal, Hooked (für Tools, die täglich genutzt werden, ist die Gewohnheitsschleife relevant)

Das ersetzt kein UX-Team. Es verhindert aber das langsamste Scheitern: Designs, die nach 2 Wochen im Einsatz gegen die Wand fahren, weil sie an einem Tag entstanden sind und niemand die Heuristiken im Kopf hatte.

Welche Werkzeuge sparen im Betrieb am meisten Zeit?

Zwei Empfehlungen aus dem Mandat: Sentry mit MCP-Integration für die Fehlersuche und Velopack für Desktop-Updates.

Sentry mit MCP-Integration. Der KI-Agent zieht Fehler live aus Sentry, liest den Stack-Trace, baut Kontext aus dem Repo und liefert einen Vorschlag für den Fix. Vom gemeldeten Fehler bis zur Behebung vergeht so deutlich weniger Zeit. Das zählt, weil Web, Windows und macOS auf einer Codebase nicht trivial sind: Die Lebenszyklen der Plattformen liegen weiter auseinander, als Mobile-Entwickler ahnen. Desktop-Lebenszyklen, Dateisystem-Rechte, Eigenheiten von CanvasKit im Web.

Velopack für automatische Updates. Desktop-Updates sind ein Schmerzpunkt, den niemand zu haben glaubt, bis das Tool 50 Nutzer hat und keiner die neue Version von Hand installiert. Velopack löst das ohne eigenen Installer-Stack: Patch-Deltas, Rollback, Signierung, eine Pipeline. Einmal aufgesetzt, muss sich das Finton-Team um nichts kümmern.

Wann ist ein Rewrite die richtige Entscheidung?

Wenn die Codebase nachweislich der Engpass ist und das Team Zeit für Fundamentarbeit hat. Prinzipiell ist fast alles inkrementell verbesserbar. Die richtige Frage ist deshalb nicht „Rewrite ja oder nein“, sondern:

• Wie viele Nutzer hängen dran? Wenige: Ein klassischer Rewrite ist billiger und schneller. Viele: die Mischung wie bei Finton.
• Wie viel Zeit hat das Team? Knapp: kein Rewrite, nur die drei schmerzhaftesten Stellen härten. Komfortabel: Die Modernisierung lohnt sich.
• Wo liegt der Engpass wirklich? Sinkt die Feature-Geschwindigkeit stetig und brauchen neue Entwickler Wochen, bis sie produktiv sind, ist die Codebase das Limit. Ist die Geschwindigkeit stabil und nur die Hardware älter geworden, brauchst du keinen Rewrite, sondern einen Profiler.

Wer dir verspricht, dass ein Rewrite immer richtig ist, verkauft Stunden. Wer „nie“ sagt, hat noch keine Codebase aus der Nähe gesehen, in der jedes neue Feature an drei Stellen bricht.

Wie läuft die Zusammenarbeit, wenn ein CTO mich bucht?

Die ersten 30 Tage gehören dem Fundament, die Übergabe beginnt am ersten Tag, und abgerechnet wird in Sprints mit festem Preis.

Die ersten 30 Tage

Viel Discovery, Architektur-Planung und Umbau an der Basis. Der erste sichtbare Output dauert länger als bei einem Junior, der sofort Feature-Tickets abarbeitet. Bei Finton waren die ersten zwei Monate Umbau, der im Frontend kaum auffiel. Ab Monat drei zog die Feature-Geschwindigkeit stark an, weil das Fundament getragen hat.

Wer schnelle Erfolge ab Woche 2 verspricht, baut entweder kein Fundament oder belügt sich selbst.

Übergabe ab Tag 1

Ich baue von Anfang an so, dass das Team ohne mich weiterläuft:

• Strukturierte, klar dokumentierte Architektur
• Ein Wiki im Repo, in dem Team und KI-Agenten Architektur-Entscheidungen nachschlagen
• Aussagekräftige Commit-Messages, damit Entscheidungen auch in 12 Monaten nachvollziehbar sind, mit oder ohne KI
• Sentry mit MCP-Integration, damit das Team Fehler selbst findet und behebt
• Aufgesetzte und dokumentierte Release-Pipelines

Ein Mandat ist erst dann gut, wenn das Team mich nicht mehr braucht.

Wie die Zusammenarbeit konkret aussieht

Am Anfang geht mehr Zeit in Linter-Einstellungen, Architektur-Entscheidungen und Konventionen. Danach liegt der Fokus aufs Coden. Kleine PRs und saubere Commits sparen am meisten Zeit. Je modularer die Codebase, desto leichter lassen sich Aufgaben aufteilen und desto seltener blockieren sich Entwickler gegenseitig. Ab einer gewissen Größe braucht es Tests, damit niemand die Arbeit der anderen versehentlich kaputt macht.

Realistisch sind 30 bis 60 Minuten Abstimmung pro Tag. Alles darüber ist Plauderei und kostet Tempo.

Scope und Preis: Sprints von 2 Wochen mit festem Preis

Pro Sprint gibt es einen klaren Scope und einen festen Preis. Verschätze ich mich, arbeite ich kostenlos weiter, bis der vereinbarte Scope geliefert ist. Ausnahme: Es kommen neue Anforderungen dazu, die außerhalb meiner Kontrolle liegen. Dann planen wir den Scope gemeinsam neu. Das Risiko der Schätzung trägt, wer schätzt. Das bin ich.

Ein kleines Team statt Agentur-Stack

Alles läuft über uns: ein kleines Team, ein Ansprechpartner. Es gibt keine Übergaben zwischen Agentur-Ebenen aus Projektmanagement, Mid und Junior, die Marge und Kontext fressen. Im KI-Zeitalter ist das wichtiger als früher: Kontext ist alles, und er zerfällt bei jeder Übergabe und sobald Leute parallel an derselben Codebase arbeiten, ohne im Kopf zu haben, was die anderen vorhaben.

Dazu kommt Senior-Erfahrung in Flutter, kombiniert mit aktiver KI-Praxis. Nicht „ich habe ChatGPT abonniert“, sondern: Ich verfolge jede Woche, was sich bei Prüfschleifen, Tool-Use, MCP und der Orchestrierung von Sub-Agenten ändert, und wende es im Code der Kunden an. Das ist mein einziger unfairer Vorteil, und ich pflege ihn aktiv.

Für wen das passt: drei Bedingungen

1. Frontend und Backend in einer Hand. Ich brauche zumindest Lesezugriff und PR-Rechte auf das Backend, damit Entscheidungen zu Performance und Datenfluss sauber bleiben. „Du machst hier nur Frontend“ funktioniert in einem produktiv genutzten Tool nicht.
2. Die Oberfläche ist klar geregelt. Entweder gibt es im Team jemanden fürs Design, mit dem ich eng arbeite, oder ich gestalte selbst mit. Halb und halb ist die langsamste Variante.
3. Druck aus der Produktion. Mein Sweet Spot sind Tools, die täglich im Geschäft genutzt werden. Braucht niemand das Tool ernsthaft, bin ich teurer als nötig. Dann nimm einen Junior.

Wer einen Body-Shop-Entwickler für Tickets sucht, ist bei mir falsch. Das spart beiden Seiten Zeit.

Ist dein internes Tool gerade der Engpass?

Dann lass uns darüber sprechen. Schreib mir über das Kontaktformular oder direkt auf LinkedIn. Ein Live-Link oder App-Store-Link zu deinem Tool hilft mir, schnell einzuschätzen, wo es hakt.