Entwicklung einer vollständigen Produktions-App mit Claude: Was wirklich funktioniert hat und was nicht

Ein Senior-Backend-Entwickler mit jahrelanger Erfahrung, aber null Kenntnissen in Flutter/Dart, entwickelte und veröffentlichte eine vollständige Produktions-App namens Warantly (Garantieverwaltung) für iOS und Android – mit Claude als primärem Entwicklungstool. Das Projekt dauerte 2,5 Monate, in denen der Entwickler abends nach der Arbeit daran arbeitete.

Der Tech-Stack

• Frontend: Flutter
• Backend: Laravel 12
• Infrastruktur: Ansible (gesamte VPS-Umgebung codifiziert, aus einem einzigen Durchlauf reproduzierbar)

Wie Claude eingesetzt wurde

Der Entwickler behandelte Claude wie einen fähigen, aber kontextbegrenzten Junior-Entwickler. Er führte mehrere Sitzungen parallel, jede auf einen einzelnen Bereich fokussiert:

• Meist 2–3 Sitzungen gleichzeitig; in Spitzenzeiten bis zu 6 parallel (3 Backend, 2 Flutter, 1 DevOps)
• Nutzte git worktrees, damit Sitzungen an verschiedenen Features arbeiten konnten, ohne sich zu widersprechen
• Seine Rolle: Architekt und Integrationsschicht – zwischen Sitzungen wechseln, Kontext bereitstellen, übergreifende Entscheidungen treffen

Was Claude gut konnte

Schnelle, kompetente erste Entwürfe klar spezifizierter Komponenten. Alles mit klarer Spezifikation und abgegrenztem Umfang kam beim ersten oder zweiten Versuch nutzbar zurück. Claude war auch wirklich gut darin, den Entwickler durch unbekanntes Terrain zu führen – Store-Compliance, Paywall-Konfiguration, Infrastrukturaufbau – Dinge, bei denen Anleitung nötig war, nicht nur Code-Generierung.

Wo es scheiterte

1. UI-Fehler

Der größte Fehlermodus. Claude kann den Bildschirm nicht sehen. Es analysierte Code, führte einen Fix durch, sagte zuversichtlich „das sollte das Problem lösen“ – und tat es nicht. Mehrere Runden am selben visuellen Bug, weil der Agent darüber nachdachte, was die UI tun sollte, anstatt zu sehen, was sie tatsächlich tat. Workaround: umfangreiche Debug-Ausgaben, manuelles Testen, genaue Laufzeitausgaben und UI-Screenshots an Claude übergeben. Der Rückkopplungskreislauf – instrumentieren, ausführen, berichten – wurde zum Standardmuster für alles Visuelle.

2. Konsistenz zwischen Sitzungen

Der Backend-Agent könnte ein Antwortformat entwerfen, das nicht dem entspricht, was der Flutter-Agent erwartet. Claude weiß nicht, was andere Sitzungen entschieden haben. Der Entwickler musste die Quelle der Wahrheit für API-Verträge, geteilte Konstanten, Namenskonventionen sein – sie manuell zwischen den Sitzungen kopieren. Wann immer dieser Schritt ausgelassen wurde, gab es bei der Integration Abweichungen.

3. Kontextabdrift in langen Sitzungen

Eine Sitzung, die lange läuft, verliert den Faden – führt bereits verworfene Muster wieder ein, widerspricht früheren Einschränkungen. Sie kündigt das nicht an. Die Ausgabe wird inkohärent zu ihrer eigenen Geschichte. Lösung: Sitzungen fokussiert und wegwerfbar halten. Neu starten, wenn sie zu lang werden. Kritischen Kontext als strukturierte Kurzfassung voranstellen, anstatt sich auf den Gesprächsverlauf zu verlassen.

Was hat funktioniert

Der Entwickler setzte Tests und statische Analyse von Tag eins an durch. Er konnte Dart/Flutter-Code nicht mit Expertenaugen prüfen, aber automatisierte Checks dienten als Qualitäts-Gate. Ohne sie hätte er nicht das Vertrauen gehabt, die App zu veröffentlichen. „Das Schwierigste war nicht technisch – es war die Kontrolle abzugeben. Ich bin ein erfahrener Entwickler und das war das erste Projekt, bei dem ich Code nicht Zeile für Zeile geprüft habe. Dem Prozess zu vertrauen (Tests bestanden, Linter sauber, Verhalten korrekt), anstatt jede Funktion zu lesen, war eine echte Umstellung.“

Die App

Warantly – Garantieverwaltung. Käufe verfolgen, Belegfotos speichern, Erinnerungen an Ablaufdaten, KI-gestütztes Scannen von Belegen, Produktrückruf-Warnungen. Kostenlos mit unbegrenzten Garantien. Pro bietet KI-Scan, Rückruf-Warnungen und Wartungspläne. Verfügbar unter warantly.app.