Eine App, die in wenigen Tagen mit Lovable gebaut wurde, fast ohne eine einzige selbst geschriebene Zeile Code, kann fertig aussehen: schönes Interface, Buttons reagieren, Daten erscheinen. Doch was wie der "letzte Schliff" aussieht, ist oft alles, was ein Demo von einem Produkt trennt - und davon gibt es mehr als von allem davor.
Dieses Phänomen hat inzwischen einen Namen: Vibe Coding. In diesem Artikel erkläre ich, was das ist, warum es für einen Prototyp genial und für ein Produkt gefährlich ist, was einer vibe-coded App konkret fehlt, wann sie völlig ausreicht (ja, manchmal reicht sie wirklich) und wie Sie aus so einem Prototyp ein echtes, produktionsreifes Produkt machen, das auch nach deutschem Maßstab DSGVO-konform und wartbar ist.
Was ist Vibe Coding
Vibe Coding ist eine Art zu programmieren, bei der Sie eine App nicht durch Schreiben von Code erstellen, sondern indem Sie einem KI-Tool in natürlicher Sprache beschreiben, was Sie wollen. "Bau mir eine To-do-App mit Login und Dark Mode" - und Sekunden später haben Sie einen laufenden Bildschirm. Die Farbe gefällt nicht? Ändern lassen. Ein Button fehlt? Hinzufügen lassen. Sie schreiben den Code nicht Zeile für Zeile, Sie steuern nach Gefühl: anfragen, Ergebnis ansehen, korrigieren lassen.
Die Tools dahinter sind bekannt: Lovable und Bolt generieren eine ganze App, v0 das Interface, Cursor und ChatGPT schreiben Code im Dialog. Das ist beeindruckende Technologie, und ich rede sie nicht klein – ich kenne diese Tools gut. Die Frage war nie, ob KI Code schreiben kann, sondern ob das, was sie geschrieben hat, der realen Welt standhält.
Denn Vibe Coding hat eine unsichtbare Eigenschaft: Es ist darauf optimiert, dass es aussieht, als ob es funktioniert. Die KI generiert Code, der den offensichtlichen Test besteht - Sie klicken auf einen Button und es passiert etwas. Aber "läuft auf meinem Bildschirm" und "läuft in Produktion für echte Nutzer" sind zwei völlig verschiedene Dinge, und genau dazwischen steckt die Arbeit, die die KI nicht von allein erledigt.
Warum es für den Prototyp großartig und für das Produkt gefährlich ist
Die Aufgabe eines Prototyps ist eine einzige: eine Idee beweisen. Es genügt, dass er für Sie einmal funktioniert, auf dem sogenannten Happy Path (so nenne ich das Szenario, in dem der Nutzer alles richtig macht und nichts kaputtgeht). Wenn Sie einem Investor zeigen wollen, wie Ihr Dienst aussehen wird, oder selbst prüfen, ob die Idee überhaupt trägt, ist Vibe Coding unschlagbar. Was früher eine Woche und mehrere tausend Euro gekostet hat, entsteht heute an einem Nachmittag. Das ist ein echter, riesiger Pluspunkt.
Die Aufgabe eines Produkts ist eine völlig andere. Ein Produkt muss nicht für Sie laufen, sondern für Fremde. Bei schlechtem Internet. Mit falsch eingegebenen Daten. Mit jemandem, der versucht, Sie zu betrügen. Nachts, während Sie schlafen. Ein halbes Jahr später, wenn sich eine Bibliothek geändert hat. Mit tausend Nutzern gleichzeitig, nicht mit einem. Genau hier beginnt der vibe-coded Prototyp zu bröckeln - und er bröckelt nicht dort, wo man es sieht, sondern dort, wo man es erst bemerkt, wenn es zu spät ist.
Die gefährlichste Illusion beim Vibe Coding
Wenn eine App zu 90 Prozent fertig aussieht, sagt die Intuition: Es fehlen noch 10 Prozent Arbeit. In der Realität ist es umgekehrt. Der sichtbare Teil (Interface, Buttons, Screens) ist der leichte, den die KI gut hinbekommt. Der unsichtbare Teil - Sicherheit, Daten, Randfälle, Deployment - ist gleichzeitig der schwerste und teuerste. Diese schweren 30 Prozent beschreibe ich gesondert im Artikel "KI-App steckengeblieben? Was Sie jetzt tun sollten".
7 Dinge, die einer vibe-coded App fehlen
In den vibe-coded Prototypen, die man mir zeigt, fehlen fast immer dieselben sieben Dinge. Nicht, weil die KI "schlecht" wäre - sie generiert genau das, worum Sie bitten, und nach diesen Dingen fragt niemand, weil man von ihnen gar nichts weiß, bis sie zum Problem werden.
| Was fehlt | Warum es in Produktion zählt |
|---|---|
| 1. Automatisierte Tests | Ohne Tests ist jede Änderung ein Glücksspiel. Sie reparieren eine Stelle - und unsichtbar geht eine andere kaputt. Im vibe-coded Code gibt es Tests so gut wie nie, weshalb das Projekt mit jeder Berührung brüchiger wird. |
| 2. Fehlerbehandlung | Was passiert, wenn das Internet abbricht, der Server nicht antwortet oder ein Nutzer Müll eingibt? Im Prototyp: weißer Bildschirm oder Absturz. Im Produkt braucht es eine klare Meldung, einen Ausweichpfad und ein stilles Protokollieren des Fehlers. |
| 3. Sicherheit | Offene API-Schlüssel direkt im Code, eine ungeschützte Datenbank, aus der jeder fremde Daten ziehen kann, keinerlei Validierung der Eingaben. Das ist die häufigste und gefährlichste vibe-coded Lücke - sie wird in Minuten ausgenutzt. |
| 4. Datenmigrationen | Wenn Sie ein Feld hinzufügen oder die Struktur ändern, müssen die bereits vorhandenen Nutzerdaten verlustfrei "umziehen". Im Vibe-Prototyp wird das Datenschema durch Löschen und Neuanlegen geändert - in Produktion hieße das gelöschte Kunden. |
| 5. Monitoring | In Produktion müssen Sie von einem Problem früher erfahren als Ihre Nutzer. Ohne Fehler-Tracking und Logs sehen Sie nicht, dass die Hälfte der Leute sich nicht einloggen kann - Sie merken es erst, wenn sie nicht mehr wiederkommen. |
| 6. Skalierung | Code, der mit einem Nutzer läuft, kann mit hundert zusammenbrechen. Unoptimierte Datenbankabfragen, kein Caching, alles in einem Thread - dem Prototyp egal, dem Produkt am ersten erfolgreichen Tag verhängnisvoll. |
| 7. Wartung | Bibliotheken altern, Sicherheitslücken tauchen auf, Regeln für Zahlungen und Login ändern sich. Ein Produkt verlangt ständige Pflege. Vibe-coded Code, den niemand versteht, wird nach der ersten ernsten Störung unreparierbar. |
Beachten Sie: Keines dieser sieben Dinge sieht der Nutzer, solange alles gut geht. Sie alle zeigen sich an diesem einen schlechten Tag - und genau ihretwegen ist ein Produkt teurer und langsamer zu bauen als ein Prototyp. Das ist kein "Lack" zum Schluss, das ist das Fundament.
Der deutsche Sonderfall: Datenschutz ist kein Detail
Bei den meisten US-Buildern wie Lovable oder Bolt laufen Daten und Hosting über US-Anbieter, ohne EU-Server und ohne Auftragsverarbeitungsvertrag (AVV nach Art. 28 DSGVO). Selbst eine "Frankfurt-Region" bei AWS, Azure oder Google reicht nicht, weil der US CLOUD Act dort hineingreift. Kostenlose ChatGPT- oder Gemini-Tarife (kein AVV, trainieren auf Ihren Eingaben) sind für den Geschäftseinsatz ein K.-o.-Kriterium. Dazu kommt der EU AI Act: seit 2024 in Kraft, mit Transparenz- und Kennzeichnungspflichten für KI-generierte Inhalte und Chatbots. Punkt 3 in der Liste oben ist deshalb in Deutschland kein technisches Detail, sondern eine rechtliche Pflicht.
Wann Vibe Coding wirklich ausreicht
Jetzt der wichtigste und ehrlichste Teil dieses Artikels. Vibe Coding ist nicht "schlecht". Es gibt viele Fälle, in denen es nicht nur ausreicht, sondern die klügste Wahl ist. Wenn Sie in einen davon fallen, beauftragen Sie mich nicht, sparen Sie Ihr Geld und bauen Sie selbst.
Hier reicht Vibe Coding wirklich
- Internes Tool für wenige Personen. Ein Rechner, eine Tabelle, ein einfaches System, das Ihr Team nutzt. Solange es keine fremden Daten hält und kein Geld annimmt - bauen Sie es mit KI und zerbrechen Sie sich nicht den Kopf.
- Demo für Investor oder Kunde. Sie müssen zeigen, wie die Idee aussehen wird. Niemanden interessiert, was unter der Haube steckt, wenn das Ziel überzeugen ist, nicht bedienen.
- Ideenvisualisierung für sich selbst. Sie wollen sehen, ob Ihr Vorhaben überhaupt Sinn ergibt, bevor Sie ernstes Geld investieren. Ein Vibe-Prototyp beantwortet diese Frage am günstigsten.
- Privates Projekt. Ein Hobby, ein persönliches Tagebuch, ein Werkzeug für sich selbst. Wenn es kaputtgeht, geht es nur Ihnen kaputt, und das ertragen Sie.
Die Faustregel ist einfach: Wenn die App keine fremden Daten hält und kein Geld annimmt, reicht Vibe Coding Ihnen höchstwahrscheinlich aus.
Wann Vibe Coding nicht mehr reicht
Und nun die andere Seite. Es gibt eine Grenze, jenseits derer "sieht aus, als ob es funktioniert" zu einem Risiko wird, das weit mehr kostet, als Sie beim Bauen gespart haben. Sie überschreiten sie in dem Moment, in dem Menschen die App nutzen, die Sie nicht kennen, oder in dem Geld durch sie fließt.
| Vibe Coding reicht | Professioneller Neuaufbau nötig |
|---|---|
| Nur Sie oder ein enger, vertrauter Kreis nutzt es | Fremde, echte Kunden nutzen es |
| Kein Geld im System | Zahlungen, Abos, Abrechnungen (PayPal, Kauf auf Rechnung, Klarna) |
| Daten unwichtig oder öffentlich | Personenbezogene Daten, DSGVO, Kundendatenschutz |
| Ein Ausfall kostet nichts | Ausfall bedeutet verlorene Kunden oder Reputation |
| Lebt ein paar Wochen | Muss jahrelang laufen und gewartet werden |
Sobald echte Kunden oder Zahlungen ins Spiel kommen, verwandelt sich jeder dieser sieben fehlenden Punkte in eine Haftung. Eine ungeschützte Datenbank mit Ihren Kunden ist keine technische Kleinigkeit mehr, sondern ein DSGVO-Verstoß mit Bußgeldrisiko. Zahlungen ohne Fehlerbehandlung sind Geld, das zwischen Ihnen und der Bank verschwindet. Und wenn Sie B2C-Kunden in Deutschland bedienen, kommen Impressumspflicht, AGB, Cookie-Consent und seit Juni 2025 die Barrierefreiheit nach dem BFSG dazu. Deshalb ist das hier keine Frage des Vibe Coding mehr, sondern eine Frage des Produkts.
Wie aus einem Vibe-Prototyp ein Produkt wird
Die gute Nachricht: Ein Vibe-Prototyp ist oft keine verschwendete Arbeit, er ist ein hervorragender Start. Sie haben bereits entschieden, was die App tut, wie sie aussieht, welche Logik sie hat. Das ist der wertvollste und am schwersten zu Papier zu bringende Teil einer Spezifikation, und er ist schon erledigt. Es bleibt, die schweren 30 Prozent zu schließen, derentwegen der Prototyp eben kein Produkt ist.
Wenn jemand mit einem vibe-coded Projekt zu mir kommt, übernehme oder flicke ich dessen Code nicht – ich baue das Produkt sauber von Grund auf, und der Prototyp wird zur Spezifikation und zum visuellen Vorbild. Die allgemeine Logik sollten Sie trotzdem kennen: Ob man auf dem bestehenden Code aufbaut oder neu aufbaut, hängt nicht von der Codemenge ab, sondern von der Struktur. Sind Logik und Datenmodell gesund, kann die fehlende Schicht auf dem bestehenden Code ergänzt werden – von Ihnen selbst oder von der Person, die ihn erstellt hat. Ist der Code chaotisch, mit offenen Schlüsseln und unkontrolliertem State, ist ein sauberer Neuaufbau schneller und günstiger als Flicken. Mehr dazu, was passiert, wenn KI-Code zu bröckeln beginnt und beim „Reparieren“ noch weiter einstürzt, schreibe ich im Artikel „Lovable, Bolt, v0, Cursor – was tun, wenn der KI-Code kaputt ist“.
Der Weg vom Prototyp zur Produktionsreife
- Spezifikation. Aus dem Prototyp leite ich Bildschirme, Abläufe und die Logik ab, die Sie bereits herausgearbeitet haben, und halte fest, was das Produkt können muss – auch das, was der Prototyp nie konnte.
- Solides Fundament. Sichere Datenbank, ordentliches Login, versteckte Schlüssel, Eingabevalidierung - das, worauf man bauen kann.
- Die schweren 30 Prozent. Zahlungen, Integrationen, Fehlerbehandlung, Randfälle. In Deutschland kommen hier oft lokale Integrationen dazu (PayPal, Klarna, SEPA-Lastschrift, E-Rechnung mit XRechnung/ZUGFeRD, DATEV-Anbindung), die die KI nicht anschließt.
- Sicherheitsnetz. Tests, Monitoring und Logs, damit Sie von einem Problem erfahren, nicht Ihr Kunde.
- Deployment und Wartung. Echte Domain, DSGVO-konformes EU-Hosting (etwa Hetzner oder IONOS), Backups und eine klare Abmachung, wer künftig pflegt.
Mein Angebot ist nie "ich räume Ihren Code auf". Es ist "ich baue, dass es läuft und Geld verdient". Der Unterschied ist entscheidend: Code aufräumen ist Kosmetik, ein Produkt bauen heißt, dass Ihre Kunden in Ruhe nutzen, zahlen und wiederkommen können - und Sie ruhig schlafen können.
Echte Zahlen
Konkret zum Preis, weil Sie ohnehin danach fragen. Ein sauberer Neuaufbau nach Ihrem Vibe-Prototyp – mit Authentifizierung, Sicherheit, DSGVO-konformem EU-Hosting und Deployment – beginnt als transparenter Festpreis ab 2.900 € (MVP / PWA, iOS und Android aus einer Codebasis). Eine Business-App mit Zahlungen, lokalen Integrationen und Admin-Bereich liegt ab 6.900 €, eine komplexe Plattform ab 14.900 €. Die Laufzeit beträgt meist 2 bis 6 Wochen, je nach Umfang und danach, wie klar der Prototyp bereits festlegt, was das Produkt können muss.
Das mag nach einigem klingen für ein "fast fertiges" Projekt. Aber denken Sie an die sieben fehlenden Dinge - Sie zahlen nicht für Lackieren, sondern für das Fundament, ohne das die App nur ein Foto eines Produkts ist. Und Sie zahlen einen Festpreis: Bei mir wissen Sie vorab, was es kostet und was geliefert wird.
Sie haben einen vibe-coded Prototyp? Ich mache daraus ein echtes Produkt.
Ihr Lovable-, Bolt-, v0- oder Cursor-Prototyp wird zur Spezifikation: Bildschirme und Abläufe bleiben erhalten, darunter baue ich von Grund auf ein stabiles Fundament – Sicherheit, Daten, Zahlungen und Deployment. MVP ab 2.900 €. Schreiben Sie mir, was Sie bauen, und innerhalb von 24 Stunden erhalten Sie ein Angebot mit Festpreis und Termin.
Meinen Prototyp neu aufbauenHäufig gestellte Fragen
Was ist Vibe Coding?
Vibe Coding ist eine Art zu programmieren, bei der Sie eine App nicht Zeile für Zeile schreiben, sondern einem KI-Tool (Lovable, Bolt, v0, Cursor, ChatGPT) in natürlicher Sprache beschreiben, was Sie wollen, und es generiert den Code. Sie steuern nach Gefühl: anfragen, Ergebnis ansehen, korrigieren lassen. Für einen schnellen Prototyp ist das hervorragend, aber dem generierten Code fehlt oft das, was Produktionsreife ausmacht: Tests, Fehlerbehandlung, Sicherheit.
Worin unterscheidet sich ein Prototyp von einem Produkt?
Ein Prototyp soll eine Idee beweisen, dafür genügt es, dass er auf Ihrem Bildschirm im Idealfall funktioniert. Ein Produkt muss in Produktion laufen, mit echten Nutzern, schlechtem Internet, falschen Eingaben und Angreifern. Den Unterschied machen Tests, Fehlerbehandlung, Sicherheit, Datenmigrationen, Monitoring, Skalierung und Wartung, also genau das, was einem vibe-coded Prototyp meist fehlt.
Kann ich einen vibe-coded Prototyp in Produktion bringen?
Technisch können Sie ihn live schalten, aber für echte Kunden oder Zahlungen rate ich davon ab. Einem Vibe-Prototyp fehlt meist Sicherheit (offene API-Schlüssel, ungeschützte Datenbank), Fehlerbehandlung und Monitoring. Der erste Angreifer oder die erste unerwartete Eingabe wirft ihn um. Vor dem Go-live braucht es jemanden, der die schweren letzten 30 Prozent schließt: Sicherheit, Daten, DSGVO, Deployment und Randfälle.
Wann reicht Vibe Coding wirklich aus?
Vibe Coding reicht, wenn die App keine fremden Daten hält und kein Geld bewegt: ein internes Tool für wenige Personen, ein Demo für Investoren, eine Ideenvisualisierung, ein privates Projekt. Wenn nur Sie selbst oder ein enger, vertrauter Kreis es nutzt, spart eine vibe-coded Lösung viel Zeit und Geld, und in dem Fall rate ich ausdrücklich nicht dazu, einen Entwickler zu beauftragen.
Was kostet es, aus einem Vibe-Prototyp ein echtes Produkt zu machen?
Das hängt davon ab, was das Produkt können muss. Ein sauberer Neuaufbau nach Ihrem Prototyp – mit Authentifizierung, Sicherheit, DSGVO-konformem EU-Hosting und Deployment – beginnt als Festpreis ab 2.900 € (MVP / PWA, iOS und Android aus einer Codebasis). Eine Business-App mit Zahlungen, lokalen Integrationen und Admin-Bereich liegt ab 6.900 €, eine komplexe Plattform ab 14.900 €. Der teuerste Teil sind immer die letzten 30 Prozent, nicht der Anfang.
Auf vibe-coded Code aufbauen oder neu aufbauen?
Die Entscheidung hängt nicht von der Codemenge ab, sondern von der Struktur. Sind Logik und Datenmodell des Prototyps gesund, kann es sinnvoll sein, die fehlende Produktionsschicht auf dem bestehenden Code zu ergänzen – das können Sie selbst tun oder mit der Person, die ihn erstellt hat. Ist der Code chaotisch, mit offenen Schlüsseln und unkontrolliertem State, ist ein sauberer Neuaufbau schneller und günstiger als Flicken. Ich arbeite ausschließlich auf diesem zweiten Weg: Fremden Code übernehme ich nicht, ich baue das Produkt von Grund auf und nutze Ihren Prototyp als Spezifikation.