Wenn deine mit KI gebaute App ihrer ersten Iteration entwächst: Refactoring vs. Neuschreiben
Du hast etwas ausgeliefert. Nutzer:innen liebten es. Jetzt sind es zehn Nutzer:innen, und ihre Bedürfnisse passen nicht zur Form, die du gebaut hast. Hier ist, wie du entscheidest, ob du die aktuelle App refactorst oder zugibst, dass sie ein Prototyp war, und sie richtig neu baust.
Du hast etwas ausgeliefert. Nutzer:innen liebten es. Jetzt sind es zehn Nutzer:innen, und sie wollen Features, die nicht zur ursprünglichen Form passen. Du stehst an einer Weggabelung: die App flicken, damit sie zum neuen Anwendungsfall passt, oder zugeben, dass die erste Version ein Prototyp war, und sie richtig bauen. Es ist die Frage, die mehr kleine Projekte umbringt als jede andere, weil es keine technische Antwort gibt — nur eine geschäftliche.
Der Moment, in dem du merkst, dass die App erfolgreich ist
Die meisten mit KI gebauten Apps starten als eine Sache und werden eine andere. Du hast ein Kundenaufnahmeformular für deine Coaching-Praxis gebaut; jetzt wollen Kund:innen vergangene Termine sehen und sich selbst umbuchen. Du hast ein Lead-Scoring-Tool gebaut; jetzt will dein Vertriebsteam Zusammenfassungen in ihr CRM exportiert haben. Du hast ein Ablagesystem gebaut; jetzt wollen Leute darin zusammenarbeiten.
Jeder Wunsch ist vernünftig. Jeder zieht die App ein Stück weg von dem, wofür sie gebaut wurde. Und an einem bestimmten Punkt — nach sechs Monaten, oder nach zwei Monaten, manchmal nach zwei Wochen — spürst du die Reibung. Alles, was du hinzufügst, kämpft gegen das Fundament. Neue Features erfordern “ach, wir müssen den Teil erst umorganisieren”. Die App wird langsamer. Es dauert länger, Dinge zu ändern.
Dieses Gefühl ist dein Signal, darüber nachzudenken, ob das noch dieselbe App ist oder ob du ihr entwachsen bist.
Was Refactoring bringt und kostet
Refactoring bedeutet, dieselbe App zu behalten, sie aber aufzuräumen, damit du mehr darauf aufbauen kannst. Du bittest deinen KI-Builder, den Code umzuorganisieren, einen überkomplizierten Workflow aufzuteilen oder einen Screen neu zu gestalten, der zur Müllhalde für Features geworden ist. Es dauert ein paar Stunden. Es fügt keine neuen Features hinzu. Es macht nur das Fundament stärker.
Wenn Refactoring funktioniert, ist es Magie. Du hattest das Gefühl, gegen die App zu kämpfen; plötzlich tust du es nicht mehr. Du fügst in einer Woche drei neue Features hinzu, die vorher drei Wochen gedauert hätten.
Aber Refactoring funktioniert nur, wenn das Problem die Form dessen ist, was du hast. Wenn du ein Aufnahmeformular gebaut hast und Nutzer:innen ein schnelleres Aufnahmeformular wollen, ist das Refactoring des langsamen Teils ein Nachmittag. Wenn sie ein Aufnahmeformular wollen, das schneller ist und einen Verlauf speichert, ist es immer noch eine App, und Refactoring könnte helfen. Aber wenn sie Terminverlauf, Kalender-Integrationen, SMS-Erinnerungen und Rechnungsstellung wollen, baust du kein besseres Aufnahmeformular mehr — du baust das Backoffice für eine Coaching-Praxis. Das ist ein anderes Produkt.
Was Neuschreiben bringt und kostet
Neuschreiben bedeutet: Du hast gelernt, was die App eigentlich sein sollte, und du baust sie mit diesem Wissen von Grund auf neu. Du wirfst die erste Version nicht weg — deine Nutzer:innen verlassen sich noch darauf. Aber du baust eine neue App von Grund auf, geprägt von dem, was die alte dich gelehrt hat, und migrierst die Nutzer:innen dann hinüber, wenn sie bereit ist.
Neuschreiben fühlt sich verschwenderisch an. Du hast etwas gebaut, und jetzt baust du es noch mal. Das ist der psychologische Preis. Der praktische Preis ist Zeit: Du wirst zwei bis vier Monate an der neuen Version verbringen, bevor sie bereit ist, Nutzer:innen zu migrieren. Du wirst die erste Version nicht mehr als Krücke haben — du drückst nach vorn ohne Netz.
Aber Neuschreiben bringt dir eine Sache, die nichts anderes kann: Freiheit. Die neue App ist nicht durch die Form der alten eingeschränkt. Wenn das Original ein simples Formular war und das neue ein vollständiges Backoffice sein sollte, designst du von Anfang an dafür. Wenn Performance zählt, designst du dafür. Wenn Sicherheit oder Integrationen oder Workflow zählen, sind sie keine Nachrüstungen — sie sind grundlegend.
Die Apps, die nach einem Neuaufbau Erfolg haben, tun das tendenziell, weil sich das Verständnis des Teams für das Problem so weit vom ursprünglichen Code entfernt hatte, dass der Versuch zu flicken war wie Kleidung zu tragen, die nicht so recht passt. Neuschreiben hieß, für sich selbst zu bauen statt.
Drei Fragen, um zwischen ihnen zu wählen
Frage 1: Ist die Kernform noch richtig?
Deine Kernform sind die ein oder zwei Haupt-Workflows, die die App definieren. Bei einem Coaching-Aufnahmeformular ist es “Kund:in füllt Aufnahme aus, Coach prüft, Coach plant Termin”. Wenn du andere Workflows hinzufügst — Rechnungsstellung, Kalenderverwaltung, Kundennachrichten —, erweiterst du nicht den Kern, du schraubst Nebenfeatures dran. Das ist ein Zeichen, dass du ein anderes Produkt baust, was Neuschreiben bedeutet.
Wenn du Variationen desselben Kerns hinzufügst — “Aufnahme für Einzelpersonen, Aufnahme für Teams, Aufnahme mit individuellen Feldern” —, ist das immer noch dieselbe App. Refactor sie und erweitere sie.
Frage 2: Wenn du heute refactorst, wie viele Monate, bis die Reibung wieder zuschlägt?
Sei ehrlich. Wenn die Reibung für sechs Monate verschwindet, ist Refactoring der richtige Zug. Wenn es in zwei Monaten wieder wehtun wird, weil das Problem nicht die Code-Form ist, sondern das Fundament selbst, dann erspart dir Neuschreiben die falsche Ersparnis, zweimal zu flicken. Frag deinen KI-Builder: “Wenn wir das aufräumen, wie lange, bis wir das wieder machen müssen?” Wenn die Antwort “wahrscheinlich nicht lange” lautet, ist es Zeit, neu zu bauen.
Frage 3: Worauf verlassen sich deine Nutzer:innen tatsächlich?
Wenn du drei aktive Nutzer:innen auf v1 hast und über einen Neuaufbau nachdenkst, kannst du sie in ein, zwei Tagen umziehen. Wenn du fünfzig Nutzer:innen hast, die produktionsabhängig von der aktuellen App sind, bedeutet Neuschreiben, dass du beide Versionen monatelang am Laufen halten musst, was eine eigene Art von Schmerz ist.
Der Weg, der meist funktioniert
Die meisten Gründer:innen, die erfolgreich neu bauen, tun es parallel: Sie halten die ursprüngliche App am Laufen und nutzen freie Kapazität, um die neue zu bauen. Wenn die neue Feature-Parität mit der alten hat, verbringen sie eine Woche damit, Daten und Nutzer:innen zu migrieren, und sind fertig.
Der Weg, der meist nicht funktioniert: refactoren, refactoren, refactoren, bis du drei Refactorings später merkst, dass die Architektur immer noch falsch ist, und jetzt zu sehr in die “alte” Version investiert bist, um es zuzugeben und von vorn anzufangen.
Der richtige Zeitpunkt zu entscheiden
Das nächste Mal, wenn du die Reibung spürst, frag dich: “Lasse ich diese App besser das tun, was sie tun sollte? Oder bitte ich sie, etwas zu sein, wofür sie nie gedacht war?” Wenn es das Erste ist, refactor. Wenn es das Zweite ist, ist es keine Schande, das Ding zu bauen, das sie von Anfang an hätte sein sollen. Die meisten erfolgreichen Apps sind auf Version 2 des Kerns, nicht auf Version 1.