Was kostet es, einen KI-Prototyp produktionsreif zu machen?
Kurz gesagt: In den meisten Fällen liegt der Aufwand bei 30 bis 60 Prozent eines Neubaus, also einige Wochen statt vieler Monate. Der Grund ist unspektakulär: 70 bis 90 Prozent eines mit Cursor, Claude oder Lovable gebauten Prototyps sind verwendbar. Es fehlen nicht Funktionen, sondern das Fundament darunter: Sicherheit, Architektur, Tests und ein sauberer Datenschutz. Die exakte Zahl entsteht erst nach einem Audit, aber die Größenordnung lässt sich seriös vorher benennen. Dieser Artikel zeigt Ihnen, wie.
Wenn Sie einen Prototyp gebaut haben, der lokal läuft, und jetzt eine Zahl brauchen, um intern eine Entscheidung zu treffen, sind Sie hier richtig.
Warum „Was kostet das?“ die falsche erste Frage ist
Ich sage das ungern, weil es nach Ausweichen klingt: Die Kostenfrage lässt sich nicht seriös beantworten, bevor jemand in Ihren Code geschaut hat. Nicht weil wir uns drücken, sondern weil bei vibecodeten Projekten der sichtbare Teil, also die App, die läuft, selten das Problem ist. Das Problem sitzt unter der Oberfläche, und dort ist bei jedem Projekt anders viel Arbeit vergraben.
Ein Prototyp, der bei zehn Testnutzern sauber funktioniert, kann eine Woche vom Produktivbetrieb entfernt sein oder acht. Der Unterschied liegt nicht in dem, was Sie sehen, sondern in drei Dingen, die Sie nicht sehen.
Die drei Kostentreiber, die niemand auf dem Schirm hat
1. Sicherheitsschulden, die still mitwachsen
KI-generierter Code ist erstaunlich gut darin, Dinge zum Laufen zu bringen, und erstaunlich schlecht darin, sie abzusichern, solange niemand explizit danach fragt. Das typische Muster: API-Keys liegen im Klartext im Frontend-Bundle, die Datenbank-Regeln (etwa Supabase Row Level Security) stehen auf „offen“, weil das im Test am schnellsten funktioniert hat. Solange nur Sie und Ihr Team die App benutzen, fällt das niemandem auf. Am Tag, an dem der erste echte Nutzer draufkommt, ist es ein Datenleck.
Diese Schuld ist der teuerste Posten, weil sie sich nicht an einer Stelle beheben lässt. Sie zieht sich durch Authentifizierung, Berechtigungen, Eingabevalidierung und Rate-Limiting, also überall dort, wo im Prototyp die Abkürzung genommen wurde. Aufräumen heißt hier: jede Abkürzung finden und einzeln geraderücken.
2. Fehlende Tests, der Grund für jede riskante Änderung
In einem Prototyp gibt es fast nie Tests. Das ist im Prototyp auch richtig, denn Sie wollten schnell herausfinden, ob die Idee trägt, und nicht ein Testframework pflegen. Nur wird ohne Tests jede spätere Änderung zum Blindflug. Niemand weiß, was kaputtgeht, wenn man an einer Stelle etwas anfasst. Ihr Team wird langsamer, je größer das Produkt wird, also das genaue Gegenteil dessen, was Sie sich vom schnellen KI-Start erhofft haben.
Der Aufbau von Tests für die kritischen Abläufe (Login, Bezahlung, Datenspeicherung) ist ein spürbarer Posten. Aber es ist der Posten, der alle zukünftigen Kosten senkt, und er zahlt sich innerhalb weniger Monate zurück.
3. Der DSGVO-Umzug, der oft unterschätzt wird
Viele KI-Prototypen entstehen auf US-Diensten, weil die am schnellsten verfügbar sind. Kundendaten landen in US-Datenbanken, Eingaben fließen in Modell-Logs von Anbietern außerhalb der EU. Für einen internen Test ist das egal. Für ein Produkt mit echten Kundendaten ist es ein rechtliches Problem, das nicht verschwindet, wenn man es ignoriert.
Der Umzug auf EU-Hosting (Hetzner, Scaleway, AWS Frankfurt) und der Ersatz von US-Diensten durch europäische Äquivalente ist selten die reine Technikarbeit, für die man ihn hält, denn oft hängen Datenmodelle und Integrationen daran. Deshalb gehört er in die Kalkulation und nicht in die Fußnote.
Was „produktionsreif“ konkret bedeutet und was nicht
„Produktionsreif“ ist kein Gütesiegel, das man aufklebt. Es ist ein Zustand, in dem vier Dinge stimmen. Die Anwendung ist sicher, sodass niemand an Daten kommt, die ihm nicht gehören. Sie ist belastbar, fällt also bei 500 Nutzern nicht um. Sie ist wartbar, sodass eine Änderung nicht drei andere Dinge bricht. Und sie ist rechtskonform, die Daten liegen also dort, wo sie liegen dürfen.
Was Produktionsreife nicht ist: ein Neuschreiben Ihres Codes, nur weil er von KI kommt. Wer Ihnen das verkauft, verwechselt Aufräumen mit Wegwerfen und rechnet auf Ihre Kosten den teureren Weg.
Warum Nachrüsten fast immer günstiger ist als Neubauen
Die Zahl, die die meisten überrascht: Das Absichern eines bestehenden Prototyps kostet typischerweise 30 bis 60 Prozent dessen, was ein Neubau kosten würde. Der Grund liegt in dem, was Sie bereits mitbringen und was in einer Neubau-Rechnung als Nullwert verbucht wird. Ihr Produkt ist bereits im Einsatz, die Fachlichkeit steckt schon im Code. Ihr Team kennt die Oberfläche und die Abläufe. Ihre ersten Nutzer sind onboard und geben Rückmeldung.
Diesen Lernfortschritt wirft ein Neubau weg, ein Hardening bewahrt ihn. Deshalb ist die ehrliche Antwort in vier von fünf Fällen: nachrüsten statt neu bauen.
Wann sich ein Neubau trotzdem lohnt
Es gibt den fünften Fall, und ich verschweige ihn nicht. Wenn der Prototyp aus Dutzenden nicht zusammenpassenden KI-Sessions besteht, wenn grundlegende Entscheidungen wie Datenmodell oder Kernabläufe in eine Sackgasse führen, oder wenn das, was Sie eigentlich brauchen, sich vom Prototyp so weit unterscheidet, dass nur die Idee bleibt, dann ist Nachrüsten das teurere Missverständnis. In diesem Fall sagen wir das offen. Es ist billiger, das einmal ehrlich zu klären, als eine wacklige Grundlage teuer zu stabilisieren.
Wie wir kalkulieren, und warum wir mit einem Audit anfangen
Wir nennen keine Zahl aus dem Bauch. Der Einstieg ist immer das Vibecode-Audit: fünf Werktage, in denen wir Security, Architektur, DSGVO und Performance strukturiert prüfen. Das Ergebnis ist ein priorisierter Maßnahmenplan, der festlegt, welche Schwachstelle wir in welcher Reihenfolge beheben, welcher Aufwand entsteht und welches Ergebnis Sie erwarten können. Erst dann steht die Zahl, und dann ist sie belastbar.
Als grobe Orientierung, nicht als Angebot: Der Aufwand skaliert vor allem mit zwei Dingen. Erstens mit der Zahl der kritischen Abläufe, die abgesichert und getestet werden müssen, also Login, Bezahlung, Datenpersistenz, Schnittstellen. Zweitens mit der Sauberkeit dessen, was schon da ist. Ein Prototyp mit klarem Kern und wenigen Integrationen ist in wenigen Wochen produktionsreif. Je mehr kritische Pfade und je verschachtelter der bisherige Code, desto weiter wandert der Aufwand nach oben. Genau diese Spanne ist der Grund, warum das Audit vor der Zahl steht.
Zwei Dinge, die viele an dieser Stelle noch fragen, will ich gleich beantworten. Sie verlieren Ihren Fortschritt nicht, denn wir schreiben nicht neu, sondern sichern ab, und in der Regel bleiben 70 bis 90 Prozent Ihres Codes erhalten. Und Sie können danach weiter mit Cursor und Claude arbeiten. Häufig richten wir Regeln und Code-Guidelines ein, die Ihre KI-Sessions direkt besser machen. Sie bleiben schnell, nur ohne das versteckte Risiko.
Sie wollen die echte Zahl für Ihr Projekt? Schreiben Sie uns kurz, was Sie gebaut haben: Tool, Stack, aktueller Stand. Wir melden uns innerhalb eines Werktages und sagen Ihnen ehrlich, wo die Risiken liegen und was der beste nächste Schritt ist.
Vibecode-Audit anfragen Erst der kostenlose Tech-Risiko-Check (3 Min.)