Was kostet es, eine vibe-codete App produktionsreif zu machen?

Du hast an einem Wochenende ein Produkt mit Lovable, Cursor oder Claude Code ausgeliefert, und jetzt will jemand dafür zahlen. Die nächste Frage hat niemand in den Prototyp eingepreist: Was kostet es, das sicher betreibbar zu machen? In diesem Post geht es um Geld und Zeit, nicht darum, ob Vibe-Coding ein Fehler war. War es nicht. Es hat dich hierher gebracht. Die Rechnung für die Teile, die das Modell übersprungen hat, kommt jetzt erst an.

Die Zahlen hier sind Spannen aus Wavects Engagement-Historie mit KI-generiertem Code, gerahmt als typisch, nicht als Angebot. Wer dir eine präzise Zahl für eine Codebase nennt, die er nie gesehen hat, rät, und der Schätzwert ist immer optimistisch. Wir scopen nach einem ersten Blick.

Wofür zahlst du eigentlich?

Du zahlst nicht dafür, funktionierende Software neu zu schreiben. Du zahlst für die Arbeit, nach der der Prompt nie gefragt hat: die Autorisierung, die das Modell im Frontend gelassen hat, die Secrets, die es inline gesetzt hat, damit das Beispiel läuft, die Queries, die mit zehn Zeilen fein und mit hunderttausend fatal sind. Nichts davon zeigt sich in einer Demo. Alles davon zeigt sich am Launch-Tag. Die Kosten für einen produktionsreifen Durchlauf sind die Kosten, diese Lücke zu finden und zu schließen, bevor ein User sie für dich findet.

Die Arbeit teilt sich in zwei Phasen, und sie werden unterschiedlich bepreist. Die erste ist das Audit: ein strukturiertes Lesen, um zu finden, was sich versteckt. Die zweite ist das Hardening: das Beheben dessen, was das Lesen zutage fördert. Der Großteil von Zeit und Geld steckt in der zweiten, aber die erste sagt dir, wie groß die zweite ist.

Was kostet das Audit selbst?

Ein Audit ist der günstige Teil, und es ist der Teil, der dir Gewissheit über alles andere erkauft. Es läuft von ein paar Tagen bis etwa einer Woche fokussierter Arbeit, je nachdem, wie groß die Codebase ist und wie viel echtes Geld oder sensible Daten sie berührt. Ein read-only internes Tool sitzt am kurzen Ende. Ein Produkt, das Zahlungen entgegennimmt und Personendaten hält, sitzt am langen Ende, weil genau das die Teile sind, die das genaueste Lesen brauchen. Das Deliverable ist ein nach Schweregrad sortierter Findings-Report und eine ehrliche Schätzung des folgenden Hardenings. Was ein Audit tatsächlich findet, liest du in unserem Beitrag zum Vibe-Coded Software Audit.

Was kostet das Hardening?

Hier landet der echte Aufwand, und er skaliert mit dem, was das Audit gefunden hat. Der ehrliche Weg, darüber zu reden, sind Spannen, weil zwei Produkte mit derselben Feature-Liste sehr unterschiedliche Arbeit brauchen können, je nachdem, was das Modell hinterlassen hat.

Behandle diese als richtungsweisend. Die Varianz innerhalb jeder Zeile wird von zwei Dingen getrieben: wie viel echtes Geld oder sensible Daten das Produkt berührt, und wie weit die KI ohne Steuerung gelaufen ist. Ein Wochenend-Prototyp, der Zahlungen und Personendaten verarbeitet, braucht mehr als ein Wochenende QA.

Wo geht die Zeit tatsächlich hin?

Leute erwarten, dass die Rechnung vom Schreiben neuen Codes dominiert wird. Wird sie nicht. Bei einem typischen vibe-codeten Hardening-Durchlauf sieht die grobe Aufteilung so aus.

• Lesen und Reproduzieren, 20 bis 30 %. Verstehen, was das Modell gebaut hat, und die Fehler reproduzieren, bevor man etwas anfasst. Du kannst nicht beheben, was du nicht als kaputt bestätigt hast.
• Autorisierung und Datenzugriff, 25 bis 35 %. Fast immer der größte Einzelposten. Zugriffsprüfungen vom Frontend auf den Server zu holen und Tenants auf Datenbankebene zu isolieren ist langsame, sorgfältige Arbeit, weil sie jeden Endpoint berührt.
• Fehlerpfade, Validierung, Secrets, 15 bis 25 %. Die unglamuröse Mitte. Error-Handling auf jedem externen Call, Input-Grenzen und Keys vom Client holen und rotieren.
• Tests und eine Regressions-Suite, 15 bis 20 %. Die Tests schreiben, die der Prototyp nie hatte, damit die nächste Änderung diese nicht rückgängig macht.

Das Muster, das Gründer überrascht: die neue Feature-Arbeit ist meist der kleinste Anteil. Der teure Teil ist die unsichtbare Infrastruktur, die eine Demo nie beansprucht.

"Die Kosten, vibe-codete Software sicher zu machen, sind nicht die Kosten, sie neu zu schreiben. Es sind die Kosten der Arbeit, nach der der Prompt nie gefragt hat, und diese Arbeit ist nicht verschwunden, weil ein Modell den ersten Entwurf geschrieben hat."

Was findet das Audit typischerweise?

Die Findings clustern, was sie schätzbar macht. Über vibe-codete Builds hinweg tauchen dieselben Punkte immer wieder auf: ein funktionierender Login ohne serverseitige Prüfung, die User A daran hindert, die Daten von User B zu lesen, Secrets im Client-Bundle, kein Error-Handling abseits des Happy Path, Queries, die bei Last kollabieren, und gar keine Tests. Die vollständige Aufschlüsselung dessen, was bricht und wie wir es nach Schweregrad sortieren, steht in unserem Post QA für KI-generierten Code, und die Schritt-für-Schritt-Migrationsarbeit in vom Lovable- und Cursor-Prototyp zur Produktion.

Was kostet es, es nicht zu tun?

Das ist der Vergleich, der zählt. Ein Hardening-Durchlauf ist eine bekannte, gescopte, einmalige Kosten. Die Alternative ist eine unbekannte Kosten, die im schlechtmöglichsten Moment bezahlt wird. Ein geleakter Payment-Key ist kein Posten, es ist ein Incident. Eine fehlende Autorisierungsprüfung ist kein Bug, es ist ein Datenleck mit regulatorischen und reputationellen Folgen. Die ehrliche Rahmung ist nicht "ein Audit kostet Geld", sondern "ein Audit ist günstige Versicherung dagegen, dieselben Lücken auf die harte Tour zu finden, nach dem Incident statt davor".

Wann ist ein Rebuild günstiger als Hardening?

Manchmal zeigt das Lesen, dass der Kern selbst falsch ist: ein Datenmodell, das nicht halten kann, was das Produkt braucht, oder dasselbe kaputte Muster über die ganze Codebase kopiert, sodass jeder Fix hundertmal gemacht werden muss. Wenn das passiert, ist den Kern neu zu bauen günstiger, als ihn ewig zu flicken, und wir sagen das im ersten Call, statt dir zu verrechnen, ein Fundament zu flicken, das neu gegossen werden muss. Ein Fundament zu flicken, das neu gegossen werden muss, ist der teuerste Weg, Geld zu sparen.

Wie bepreist Wavect diese Arbeit?

Wir nutzen agilen Festpreis, sobald das Audit die größten Unbekannten beseitigt hat. Das Audit ist eng und klein gescopt. Das Hardening wird aus dem gescopt, was das Audit gefunden hat, mit Blockern, Highs und Cleanup getrennt, sodass du entscheidest, was und wann du finanzierst. Du wirst nie gebeten, eine Festzahl für Arbeit zu unterschreiben, die noch niemand angesehen hat. Das ist das Front-End unseres Software-Quality-Assurance-Service.