Zu Gast bei programmier.bar: Warum wir auf Low-Code setzten und wieder davon wegkamen

Recap zu Deep Dive 168: In der programmier.bar diskutierten wir unsere Erfahrungen mit FlutterFlow bei Memoro. Eine Analyse der Grenzen von Low-Code.

Projekt ansehen

Deep Dive 168: Ein Rückblick auf unsere Low-Code-Reise

Es war Zeit, Tacheles zu reden: In der Episode Deep Dive 168 des Podcasts programmier.bar waren Till Schneider und ich im Dezember 2024 zu Gast, um die Entstehungsgeschichte von Memoro offen zu legen. Im Gespräch mit den Hosts bot sich die perfekte Gelegenheit, unsere technologische Reise zu reflektieren – warum wir uns initial voll auf FlutterFlow als Low-Code-Plattform verlassen haben und welche schmerzhaften Grenzen uns schließlich zwangen, den Stack komplett zu wechseln.

Dieser Artikel fasst die Kernpunkte unseres Podcast-Gesprächs zusammen und beleuchtet die Hintergründe, die wir in der Sendung diskutiert haben.

Memoro entstand ursprünglich auf einem Hackathon in Konstanz. Die Idee: Gespräche und Gedanken per Sprachnotiz festhalten und mittels KI strukturieren. Das Kernteam bestand aus Till Schneider (Design) und mir (Development). Wie im Podcast besprochen, wählten wir FlutterFlow, um schnell einen funktionsfähigen Prototypen zu erstellen. Till konnte ohne klassische Programmierkenntnisse direkt im Frontend iterieren, was die Zusammenarbeit erheblich beschleunigte. Innerhalb von zwei Wochen hatten wir eine Alpha-Version, die wir an Testnutzer verteilten.

FlutterFlow bot integrierte Lösungen wie Firebase und Firestore, was das Setup vereinfachte. Zudem ermöglichte die Plattform die Integration von Custom-Code, was für spätere Anpassungen entscheidend war. Geschwindigkeit war im Hackathon-Umfeld der kritische Faktor. Low-Code ermöglichte uns, etwa 400 Versionsnummern in rund 1,5 Jahren zu erreichen, durchschnittlich neun Versionen pro Woche.

Ich bin überzeugt, dass Low-Code für den Einstieg die richtige Wahl war, um schnell Feedback zu sammeln und das Produkt zu validieren. Die Plattform ermöglichte uns einen Start ohne technische Schulden. Allerdings war die Entscheidung für FlutterFlow pragmatisch, aber mit dem Wissen verbunden, dass wir später auf einen eigenen Stack wechseln müssten, besonders bei wachsender Komplexität.

Till Schneider sagte im Podcast passend dazu: “Ich hätte nicht anfangen können, Tobi zu helfen, wenn wir nicht mit Low-Code gestartet wären.”

Die ersten Hürden: Wo FlutterFlow an seine Grenzen stieß

So gut der Start war, die Probleme ließen nicht lange auf sich warten – ein Thema, das im Deep Dive viel Raum einnahm. Der einfache Recorder von FlutterFlow unterstützte keine Hintergrundaufnahmen oder Screen-Sperre, was für Memoro als Kernfeature essenziell war. Ein Custom-Recorder musste innerhalb der ersten Entwicklungswochen implementiert werden. Ein weiteres kritisches Beispiel war ein Memory Leak im eingebauten Timer-Widget, das uns zwang, einen Custom-Timer zu bauen.

Till Schneider beschrieb das Performance-Problem im Gespräch so: “Der eingebaute Timer von FlutterFlow hat diesen Memoryleak wohl verursacht, aber es war dann doch nicht das Hauptproblem, sondern ein tiefer liegendes Problem, und wir kamen da partout nicht dahinter.”

Die Abhängigkeit von der Plattform wurde zunehmend zum Risiko:

Debugging als Blackbox: Wir hatten öfters plötzlich Errors, die wir vorher nicht hatten. Nach Debugging stellte sich heraus, dass sich Dependencies geändert hatten – entweder durch FlutterFlow-Updates oder durch eigene Abhängigkeiten.
Plattform-Updates: Änderungen verursachten unerwartete Fehler, zum Beispiel zusätzliche Permissions für Background-Aufnahmen auf Android, die manuell nachgepflegt werden mussten. Ein Bug in FlutterFlow führte sogar dazu, dass Übersetzungen in 24 Sprachen regelmäßig gelöscht wurden.
Kollaboration: Paralleles Arbeiten an derselben UI führte zu spontanen Änderungsverlusten, obwohl eine git-ähnliche Versionskontrolle existierte.

Zusätzlich stiegen die Build-Zeiten mit wachsender Komplexität auf bis zu 10 Minuten pro Hot-Reload, was die Iterationsgeschwindigkeit, die eigentlich der Vorteil von Low-Code sein sollte, massiv ausbremste.

Der Wendepunkt: Warum wir uns für einen Stack-Wechsel entschieden

Mit wachsender Nutzerzahl – wir hatten über 1.300 Nutzer erreicht – und zunehmender Komplexität wurde FlutterFlow zum Flaschenhals. Wir brauchten mehr Kontrolle über den Stack. Die Integration von In-App-Payments und Abomodellen war zwar möglich, aber fehleranfällig. Langfristige Anforderungen wie On-Premise-Hosting waren mit FlutterFlow schlicht nicht umsetzbar.

Till Schneider fasste unsere Überlegungen im Podcast zusammen: “Wir kamen dann zu der Erkenntnis: Wenn wir uns angucken, wie viel der Durchschnittsnutzer Memos hat, merkt er das Problem gar nicht. Also machen wir uns jetzt deswegen verrückt oder schieben wir das Problem vor uns her? […] Wir waren dann an ‘nem gewissen Punkt, da war uns klar: Okay, wir sollten den Stack wechseln.”

Der Wechsel zu React Native basierte auf mehreren Faktoren:

Kontrolle: Volle Hoheit über Code, Updates und Infrastruktur.
Performance: Behebung von Memory-Leaks und langsamen Build-Zeiten durch eigene Implementierung sowie Optimierungen durch Meta (VR-Headsets).
Neue Möglichkeiten durch KI: KI-Tools wie Cursor und Windsurf machten Custom-Code-Entwicklung für unser Team inzwischen schneller als Low-Code. Sie ermöglichten schnelle Code-Generierung und Debugging ohne die hinderliche Abstraktionsebene.

Wir peilten an, eine stabile Version zu haben, die wir “in Ruhe lassen” können, um dann den Cut zu machen und auf den eigenen Stack zu migrieren.

Lessons Learned: Was wir aus der Low-Code-Erfahrung mitnehmen

Low-Code ist ein pragmatisches Werkzeug für Prototyping und einfache Anwendungen, aber oft kein nachhaltiger Stack für wachsende Produkte mit Performance- oder Multiplattform-Anforderungen. Die Abhängigkeit von Low-Code-Plattformen wird zum Risiko, sobald die App über einen Prototypen hinauswächst.

Till Schneider verglich es treffend: “FlutterFlow war wie ein breiter Pinsel: schnell für den Anfang, aber irgendwann merkt man, dass man mehr Präzision braucht.”

Basierend auf unserer Diskussion im Podcast lässt sich klar abgrenzen, wann welcher Ansatz sinnvoll ist:

Wann Low-Code sinnvoll ist:

Schnelle Prototypen (Hackathons, interne Tools).
Teams ohne Coding-Erfahrung (Designer, Produktmanager).
Einfache CRUD-Anwendungen (Dashboards, Formulare).

Wann man zu Code (ggf. mit KI-Support) wechseln sollte:

Performance-intensive Features (Echtzeit-Audio, komplexe Berechnungen).
Multiplattform-Anforderungen (Web + Mobile + Desktop) mit spezifischen Native-Features.
Langfristige Wartbarkeit (Vermeidung von Plattform-Lock-in und Breaking Changes durch Updates).

KI-Tools wie Cursor oder Windsurf sind heute eine effektive Alternative zu Low-Code, wenn das Team bereits Coding-Erfahrung hat. Sie vermeiden den Lock-in und bieten dennoch hohe Geschwindigkeit.

Fazit: Low-Code im Rückspiegel – und ein Blick nach vorn

Der Wechsel war notwendig, um Qualität und Skalierbarkeit von Memoro langfristig zu sichern. Memoro existiert weiterhin produktiv, wie der Hall-of-Fame-Eintrag auf programmier.bar bestätigt.

Rückblickend würden wir den Weg vermutlich wieder so gehen: Schnell starten mit Low-Code, um die Idee zu validieren, aber den Absprung früher planen, sobald die technischen Anforderungen steigen.

Das finale Fazit gehört Till Schneider, wie er es im Podcast formulierte: “Low-Code ist wie ein Mietwagen: gut für die Fahrt zum Flughafen, aber kein Auto für die Langstrecke.”

Cite this article Tobias Müller (2026): Zu Gast im programmier.bar Podcast: Warum wir auf Low-Code setzten und wieder davon wegkamen. https://ispringen.dev Lizenz: CC BY 4.0 – Bitte mit Namensnennung „Tobias Müller, ispringen.dev“.