Sie haben etwas in Lovable, Replit, Bolt oder v0 gebaut, also per „Vibecoding“: Sie beschreiben, was Sie wollen, und ein KI-Tool schreibt den Code. Es funktioniert. Leute haben sich durchgeklickt, ein paar haben sich registriert, und vielleicht hat einer sogar bezahlt. Das ist nicht nichts. Vor sechs Monaten hätten Sie dafür einen Entwickler einstellen oder selbst programmieren lernen müssen. Sie haben es an einem Wochenende geschafft.
Jetzt hängen Sie an einer anderen Frage, und genau die zählt: Bauen Sie auf diesem Ding weiter, oder fangen Sie neu an?
Die kurze Antwort: Das ist eine geschäftliche Entscheidung, keine Code-Review. Bauen Sie auf dem Prototyp weiter, solange er Nachfrage beweist und nichts Sensibles darauf läuft. Bauen Sie den Kern neu, sobald echte Nutzer, echte Daten oder echtes Geld davon abhängen. Die drei Fragen unten treffen die Entscheidung für Ihren konkreten Fall.
Fast jeder Gründer stellt die Frage falsch. Er fragt „ist mein Code gut?“, und darauf gibt es keine Antwort, weil Sie ihn nicht lesen können. Ehrlich gesagt lautet die Antwort bei jedem jemals ausgelieferten MVP „nein“, ob vibecodet oder nicht. Die eigentliche Frage ist nicht die Codequalität. Es geht um weiterbauen oder neu bauen, und das ist zuerst eine geschäftliche Entscheidung und erst dann eine technische.
Warum ist „weiterbauen oder neu bauen“ überhaupt ein Dilemma?
KI-Builder sind außergewöhnlich gut in genau einer Sache: Sie bringen Sie zu 80 % einer Demo. Bei den letzten 20 %, die aus einer Demo ein Produkt machen, sind sie nahezu nutzlos.
Das ist keine Kritik an den Tools. Genau dafür sind sie gemacht. Lovable erzeugt Ihnen in zwanzig Minuten bereitwillig ein Registrierungsformular, ein Dashboard und eine Datenbank. Was es nicht entscheidet: wer welche Zeile dieser Datenbank lesen darf, was passiert, wenn zwei Nutzer gleichzeitig denselben Datensatz bearbeiten, wo Ihr Stripe-Secret-Key liegt und was mit der App bei 10.000 statt zehn Nutzern passiert. Das sind keine Features, die Sie zu prompten vergessen haben. Das sind die unsichtbaren 80 % echter Software, und der Generator hat dazu keine Meinung.
So entsteht etwas, das zu 80 % fertig aussieht und tatsächlich 80 % des Weges zu einer Demo zurückgelegt hat, was vielleicht 20 % des Weges zu einem Produkt sind. In der Lücke zwischen diesen beiden Zahlen treffen Gründer entweder eine kluge Entscheidung oder verbrennen sechs Monate.
Welche drei Fragen entscheiden über weiterbauen oder neu bauen?
Vergessen Sie den Code. Stellen Sie diese drei Fragen, in dieser Reihenfolge.
1. Trägt das System schon Last?
Last tragen heißt: Fließt echter Wert durch dieses System, den Sie sich nicht leisten können zu verlieren oder zu beschädigen? Echte Nutzerdaten, echte Zahlungen, echte Datensätze, auf die sich jemand verlässt. Ein Prototyp, an dem zehn wohlwollende Beta-Nutzer herumprobieren, trägt keine Last. Eine App, in der zahlende Kunden Daten speichern, deren Verlust sie zur Weißglut bringen würde, trägt sehr viel Last. Je mehr Gewicht das System trägt, desto weniger dürfen Sie es nebenbei behandeln, und desto schneller wird aus „das reparieren wir später“ ein Ausfall.
2. Wie weit ist es von echten Nutzern oder echtem Geld entfernt?
Entfernung ist Zeit. Wenn Sie nur noch Wochen davon entfernt sind, das Produkt zahlenden Nutzern zu zeigen, läuft die Uhr für die unsichtbaren 80 % bereits. Wenn Sie noch validieren und es in den nächsten sechs Wochen ums Lernen und nicht ums Skalieren geht, haben Sie Spielraum, schnell weiterzumachen. Die Frage ist nicht, ob die Schulden existieren, sie existieren. Die Frage ist, ob sie in diesem Quartal fällig werden oder nächstes Jahr.
3. Was kostet es Sie, falsch zu liegen?
Diese Frage überspringen Gründer. Was passiert tatsächlich, wenn das Auth-Modell ein Leck hat und ein Kunde die Daten eines anderen sieht? Wenn die Datenbank keine Backups hat und eine fehlerhafte Migration eine Woche an Datensätzen löscht? Wenn eine Sicherheitslücke genau in der Woche auftaucht, in der Sie eine Finanzierungsrunde abschließen? Bei manchen Produkten ist das eine peinliche E-Mail. Bei einem Fintech, einer Gesundheits-App oder allem, woran Verträge hängen, ist es das Unternehmen. Bewerten Sie das Risiko ehrlich, denn diese Zahl entscheidet, wie viel fehlende Sorgfalt Sie sich leisten können.
Drei Fragen. Last, Entfernung, Kosten eines Irrtums. Lassen Sie Ihr MVP durch diese drei laufen, bevor irgendjemand den Code anfasst.
Wann wird Ihr Prototyp still und leise zu tragenden Schulden?
Manches von dem, was Ihnen der Generator geliefert hat, können Sie behalten. Manches ist eine Rechnung, die noch nicht angekommen ist. Sie müssen das nicht auf Code-Ebene diagnostizieren. Sie müssen die Warnsignale kennen, damit Sie sie als Entscheidungsgrundlage gewichten können. Je mehr davon Sie wiedererkennen, desto mehr spricht für „jetzt absichern, nicht später“:
- Secrets im Frontend. API-Keys, Datenbank-Zugangsdaten oder Tokens von Drittanbietern, die an den Browser ausgeliefert werden, wo jeder sie lesen kann. Das finden wir mit Abstand am häufigsten, und es kostet echtes Geld, wenn jemand über Nacht Ihr OpenAI- oder Stripe-Konto leerräumt.
- Kein echtes Auth-Modell. „Eingeloggt“ ist nicht dasselbe wie „darf das sehen“. Wenn jeder angemeldete Nutzer die Daten jedes anderen lesen kann, indem er eine ID in der URL ändert, haben Sie keine Zugriffskontrolle, sondern einen Login-Bildschirm vor einer offenen Tür.
- Eine Datenbank ohne Struktur. Flache Tabellen, keine Relationen, keine Indizes und, das ist der Punkt, an dem Unternehmen scheitern, keine Backups und kein Migrationskonzept. Wenn Sie zum ersten Mal die Struktur Ihrer Daten ändern müssen, während echte Datensätze darin liegen, erfahren Sie, was das kostet.
- Keine Tests für die Geldflüsse. Niemand erwartet von einem MVP vollständige Testabdeckung. Aber wenn der Code, der Karten belastet oder Guthaben bewegt, null Tests hat, ist jede künftige Änderung ein Münzwurf, ob Sie versehentlich jemanden doppelt belasten.
- Spaghetti in einer einzigen Datei. Geschäftslogik, UI und Datenzugriff ineinander verknotet, fünfmal kopiert. Es funktioniert, bis Sie eine Sache ändern müssen und zwei andere kaputtgehen, von denen Sie nichts mehr wussten. Diese Steuer zahlen Sie bei jedem neuen Feature, für immer, bis jemand den Knoten löst.
Nichts davon bedeutet „neu anfangen“. Es bedeutet: Der kostenlose Teil des Vibecodings ist vorbei, und das echte Engineering hat noch nicht begonnen. Das ist der ehrliche Übergangspunkt, und an genau diesem Punkt zu wissen, ob Sie refaktorieren, neu bauen oder die Plattform wechseln sollten, ist die Senior-Entscheidung, für die den meisten Gründern niemand am Tisch sitzt.
Was bedeutet „produktionsreif“ hier eigentlich?
„Produktionsreif“ wird behandelt, als wäre es ein Häkchen. Ist es nicht. Für eine vibecodete App läuft es auf fünf Dinge hinaus, die vorhanden statt abwesend sein müssen:
- Sicherheit. Secrets auf dem Server, abgesicherte Endpunkte, nichts Sensibles verlässt den Client.
- Ein Datenmodell, das hält. Echte Relationen, Migrationen, Indizes, Backups. Daten, deren Struktur Sie ohne Angst ändern können.
- Eine echte Auth- und Zugriffsschicht. Authentifizierung und Autorisierung: wer eingeloggt ist und was er anfassen darf.
- Observability. Wenn um 3 Uhr nachts etwas kaputtgeht, erfahren Sie es aus Ihrem Monitoring, nicht aus dem wütenden Tweet eines Kunden.
- Wartbarkeit. Eine Codebasis, die Ihr nächster Entwickler lesen und erweitern kann, ohne sie löschen zu wollen.
Das ist die Tiefe der Arbeit, und es ist ein echtes Stück Engineering, genug, dass wir einen eigenen Service rund darum aufgebaut haben, vibecodete Prototypen in Produktion zu bringen, statt es in einem Blogartikel abzuhandeln. Für Ihre Entscheidung heute zählt etwas Einfacheres: Keiner dieser fünf Punkte kommt aus dem Generator, und alle fünf lassen sich erreichen, ohne wegzuwerfen, was Sie haben.
Das ehrliche Urteil
So fällt die Entscheidung in der Regel aus.
Bauen Sie in Lovable oder Replit weiter, wenn Sie noch validieren. Wenn Sie noch keine echten Nutzer, kein echtes Geld und keine echten Kosten eines Irrtums haben, ist Engineering-Sorgfalt jetzt verfrühte Optimierung, die sich als Gründlichkeit verkleidet. Vibecoden Sie weiter. Lernen Sie schneller. Kommen Sie zu diesem Artikel zurück, wenn die drei Fragen anfangen, mit „ja“ zu antworten. Manchmal ist der klügste Schritt, genau so weiterzumachen.
Sichern Sie die bestehende App ab, wenn das Produkt bewiesen ist, aber das Fundament weich, und das ist meistens der Fall. Sie haben Nutzer, die UI und die Kernlogik sind es wert, behalten zu werden, und gefährlich ist die unsichtbare Schicht: Auth, Secrets, Datenmodell, Deployment. Das ist der Normalfall, und er erfordert fast nie einen kompletten Neuschrieb. Sie behalten, was funktioniert, bauen neu, was nicht funktioniert, und haben am Ende dasselbe Produkt auf einem Fundament, auf dem Sie wachsen können.
Bauen Sie den Kern neu, wenn die tragenden Teile grundlegend falsch für Ihr Ziel sind: ein Datenmodell, das nicht abbilden kann, was das Geschäft tatsächlich braucht, oder eine Architektur, die sich gegen jedes neue Feature sträubt. Selbst hier heißt „den Kern neu bauen“ selten „alles neu bauen“. Die UI überlebt meistens. Ersetzt wird der Motor darunter.
Beachten Sie, was nicht auf dieser Liste steht: „alles wegwerfen und mit einem leeren Repository neu anfangen“. Ein kompletter Neuschrieb von null ist viel seltener die Antwort, als Gründer befürchten, und viel seltener, als Agenturen Ihnen erzählen werden, denn ein Neuschrieb lässt sich abrechnen und wirkt beruhigend entschlossen. Die ehrliche Antwort liegt meistens irgendwo in der Mitte, und genau herauszufinden, wo, ist die eigentliche Arbeit.
Wie es weitergeht
Wenn Sie an dieser Weggabelung stehen, müssen Sie kein technischer Experte werden, um die Entscheidung zu treffen. Sie brauchen jemanden mit Erfahrung, der sich ansieht, was Sie gebaut haben, und Ihnen die Wahrheit sagt: weiterbauen, absichern oder den Kern neu bauen, mit einer konkreten Zahl und ohne Anreiz, sie aufzublähen.
Dieses Gespräch führen wir jede Woche. Schicken Sie uns Ihr Lovable- oder Replit-Projekt und buchen Sie ein 20-minütiges Scoping-Gespräch. Wir sagen Ihnen, bei welchem der drei Urteile Ihre App landet, ehrlich, auch wenn die Antwort lautet: „Vibecoden Sie weiter, so weit sind Sie noch nicht.“ Wenn Sie so weit sind, setzen unser Fractional CTO und unsere Produktionsarbeit mit festem Umfang genau dort an, wo der Generator aufgehört hat.
Über den Autor: Konstantinos Tsolakidis ist Gründer von WeAreFabbrik und arbeitet als Fractional CTO für finanzierte Startups in ganz Europa. WeAreFabbrik ist ein Senior-Engineering-Team mit Sitz in Athen und Tallinn, das seit 2018 über 50 KI-, SaaS- und Automatisierungsprodukte ausgeliefert hat.