Lovable, Bolt, v0: Wenn Vibe-Coded MVPs zur Tech-Schulden-Hypothek werden

Vibe-Coded Apps wie Lovable, Bolt und v0 sind hervorragend für Prototypen und vollständig ungeeignet als produktive MVPs. Wenn wir ein solches Projekt übernehmen, bauen wir es jedes Mal von Grund auf neu, denn die Bereinigung von Struktur, Hooks und Authentifizierung kostet mehr als ein Neustart. Dieser Beitrag zieht die Grenze zwischen dem Prototypen, den diese Tools leisten können, und dem MVP, den sie nicht leisten können.

Heute kann jeder coden. Ein Gründer ohne technischen Hintergrund kann ein SaaS-Produkt am Samstagmorgen in einfachem Deutsch beschreiben und bis zum Mittagessen unter einer öffentlichen URL zugänglich machen. Das ist eine echte Veränderung in der Art, wie Software entsteht, und das ist überwiegend positiv. Gleichzeitig hat sich dadurch ein neues Versagensmuster etabliert, das vor zwei Jahren noch nicht existierte: Produktions-Apps, die niemand im Unternehmen lesen kann.

Wir sprechen jede Woche mit Gründern, die ein Lovable-Projekt veröffentlicht, ihre ersten drei Kunden gewonnen haben und dann gegen eine Wand stoßen, die sie nicht benennen können. Die Plattform hat die Arbeit erledigt. Die Plattform hat dabei auch jede Architekturentscheidung getroffen, bevor der Gründer wusste, welche davon wichtig waren.

Dieser Artikel richtet sich nicht gegen Lovable, Bolt oder v0. Sie haben ihren Platz in der Prototypen-Phase. Wir ziehen die Grenze aus Kundenperspektive: Was liefern diese Tools im Vergleich zu dem, was ein MVP benötigt, um seinen ersten zahlenden Kunden zu überstehen, und welche Muster sehen wir in jeder Codebase, die wir übernehmen.

• Vibe-Coding gewinnt in der Prototypen-Phase, wo Geschwindigkeit wichtiger ist als Struktur und nichts an Kunden ausgeliefert wird.

• MVPs scheitern anders als Prototypen. Authentifizierung, Multi-Tenancy, ein Admin-Interface und Observability sind nicht verhandelbar, sobald sich ein echter Kunde anmeldet.

• Die Bereinigungskosten entsprechen den Neubaukosten. Jedes Vibe-Coded MVP, das wir übernehmen, bauen wir von Grund auf neu. Das Lovable-Projekt war versunkener Aufwand, keine gesparte Zeit.

• Das Muster ist konsistent. Schlechte Struktur, useEffect-Missbrauch, unnötige Re-Renders, offene Backend-Routen, schludrige Authentifizierung, in dieser Reihenfolge.

• Nutzen Sie Lovable für das, worin es gut ist. Demos, interne Mockups, Ideenexploration. Beauftragen Sie Ingenieure für alles, wofür ein Kunde zahlt.

Heute kann jeder coden (und das ist überwiegend in Ordnung)

Die Hürde zu "Ich habe etwas gebaut" ist 2025 gefallen. v0 liefert eine Next.js-Komponente aus einem Screenshot, Lovable erstellt ein Supabase-Backend aus einem Absatz, Bolt baut eine bereitgestellte App in einem einzigen Chat, und Replit Agent führt die gesamte Schleife aus, bis etwas kompiliert.

Das ist ein echter Gewinn für die Ideenexploration. Ein Nicht-Ingenieur, der früher drei Wochen damit verbrachte, einen Freiberufler zu finden, kann drei Stunden damit verbringen, die Idee in echten Pixeln zu validieren. Ein Designer kann die Demo für seine Pitch-Präsentation bauen, anstatt sie in Figma zu skizzieren. Keiner dieser Anwendungsfälle erfordert Produktionsdisziplin.

Die Schwierigkeiten beginnen beim nächsten Schritt, wenn der Prototyp in "MVP" umbenannt, einem zahlenden Kunden gezeigt und als Produktionssoftware behandelt wird. Das Werkzeug kündigt nicht an, wenn die Grenze überschritten wird. Der Gründer merkt es selten.

Prototyp-Grenze versus MVP-Grenze

Ein Prototyp ist eine Frage. Ein MVP ist ein Vertrag.

Ein Prototyp fragt: Ergibt diese Idee in Pixeln Sinn? Er läuft lokal, scheitert sichtbar und wird an niemanden ausgeliefert. Das Versagensmuster ist: "Ich bemerke, dass etwas falsch ist, und korrigiere den Prompt." Es ist ein Lernprodukt, und die einzigen Betroffenen sind der Gründer und ein wohlgesonnener Mitstreiter.

Ein MVP ist die erste Version, die zahlende Kunden berühren. In dem Moment, in dem Geld oder persönliche Daten den Besitzer wechseln, ändert sich auch der implizite Vertrag. Der Kunde erwartet, dass sein Login weiterhin funktioniert, seine Daten privat bleiben und die App seine Sitzung nicht verliert, weil ein useEffect zweimal ausgeführt wurde. Das sind keine fortgeschrittenen Anforderungen, das ist die Mindestanforderung.

Der Grund, warum die meisten Vibe-Coded Apps diese Grenze stillschweigend überschreiten, liegt darin, dass das Tool immer wieder "produktionsreif" sagte, während es einen Prototypen lieferte. Die Prüfung, die das Überschreiten erkennt, ist menschlich, nicht technisch: ein Gründer, der weiß, was ein MVP können muss, bevor er Geld annehmen kann.

Wenn die Grenze finanziell relevant ist, ist der richtige Schritt, Ingenieure einzustellen, nicht einen schnelleren Prompt zu formulieren. Wir führen MVP-Entwicklungen in einem festen Zeitrahmen von 3 bis 5 Wochen durch, mit Authentifizierung, Abrechnung, einem Admin-Interface und Observability ab dem ersten Tag.

Was wir tatsächlich in Vibe-Coded-Codebases finden

Wenn uns ein Gründer ein Lovable- oder Bolt-Projekt zur Bereinigung übergibt, ist das Muster so konsistent, dass wir wissen, was wir finden werden, bevor das Repository fertig geklont ist. Fünf Probleme, grob in der Reihenfolge, in der sie schmerzen.

Schlechte Struktur. Dateien benannt nach dem Prompt, der sie erzeugt hat, Komponenten vier Ebenen tief verschachtelt ohne Wiederverwendungsgrenze, ein "utils"-Ordner, der die gesamte Business-Logik der App enthält. Die Codebase ist ein Protokoll der KI-Gedanken, keine Beschreibung dessen, was die App tut. Ein Feature hinzuzufügen bedeutet, die Hälfte des Projekts zu lesen, um herauszufinden, wo der Zustand liegt.

useEffect-Missbrauch. Jeder Datenabruf lebt in einem useEffect, jede Prop-Änderung löst einen erneuten Abruf aus, und Effekte hängen von Objekten ab, die bei jedem Render neu erstellt werden. Die App bombardiert das Backend beim ersten Laden mit doppelten Anfragen und blockiert dann, wenn eine dieser Anfragen stillschweigend fehlschlägt. Das Muster verstärkt sich, sobald Formulare hinzukommen.

Unnötige Re-Renders. Globaler Zustand lebt in einem Context-Provider, der die gesamte App umschließt, sodass jede Komponente bei jedem Tastendruck neu gerendert wird. Die App fühlt sich bei 10 Einträgen in einer Liste langsam an und ist bei 100 Einträgen nicht mehr nutzbar. Die Lösung erfordert echtes React-Wissen, das der Prompt nie eingefordert hat.

Offene Backend-Routen. Supabase-Tabellen mit deaktiviertem RLS oder auf "authenticated" gesetzt ohne Zeilenbeschränkung, Server-Aktionen, die einer clientseitig gesendeten user_id vertrauen, Edge-Funktionen, die jede Payload akzeptieren, weil die Validierung im Formular lag. Ein Nutzer in einem Inkognito-Fenster kann alle Zeilen in der Tabelle auflisten.

Schludrige Authentifizierung. Sitzungsprüfungen clientseitig durchgeführt, Rollenprüfungen mit String-Vergleichen gegen Felder, die die KI erfunden hat, Passwort-Reset-Abläufe, die dasselbe Token-Format an jeden Nutzer senden, JWT-Geheimnisse in der .env.example-Datei, die ins öffentliche Repository eingecheckt wurde. Manchmal ist der anon-Schlüssel das Einzige, was zwischen der App und "Ich bin jetzt Admin" steht.

Das sind keine Ausnahmefälle. Das ist das mittlere Ergebnis von "KI hat das ohne Ingenieur im Prozess geliefert", was wir aus technischer Sicht in warum KI-generierte Software weiterhin Engineering-Review benötigt behandelt haben.

"Es funktioniert" ist das schlechteste Signal, dem Sie vertrauen können

Das Gefährliche ist nicht, dass Vibe-Coded Apps versagen. Schlechter Code bricht sichtbar und wird behoben. Das Gefährliche ist, dass sie funktionieren. Die Demo läuft, die ersten 10 Bekannten registrieren sich, der erste Kunde zahlt, und der Gründer schlussfolgert, dass das Projekt in Ordnung war.

Die Tech-Schulden wachsen still, bis etwas sie sichtbar macht. Die auslösenden Faktoren sind vorhersehbar:

• Erster echter zahlender Kunde. Seine Daten überqueren Ihre Autorisierungsgrenze. Die Grenze fehlt oder ist falsch. Sie erfahren es durch ein Support-Ticket, nicht durch einen CI-Test.

• Erste Feature-Anfrage nach dem Launch. Das Datenmodell der KI hat einen Nutzer pro Workspace angenommen. Der Kunde möchte zwei. Den zweiten Nutzer hinzuzufügen berührt 14 Dateien, die niemand je gelesen hat.

• Erstes Sicherheits-Review. Ein B2B-Interessent fragt nach SOC2-Dokumenten oder einem Pentest. Der Pentester findet die offenen Routen in 20 Minuten. Der Deal stockt oder scheitert.

• Erster Admin-Bedarf. Der Gründer muss einen Kunden erstatten, einen Bot sperren oder die Registrierungen der letzten Woche einsehen. Es gibt keine Admin-Seite, und es gibt keine Möglichkeit, eine hinzuzufügen, ohne das Routing neu zu gestalten.

• Erstes Skalierungsereignis. Ein Blogbeitrag sorgt für Aufmerksamkeit, der Traffic steigt, und die App bricht zusammen, weil jedes Render alle Zeilen abruft. Die Lösung ist das oben beschriebene Re-Render-Problem.

Jeder auslösende Faktor verwandelt unsichtbare Schulden in einen Ausfall, einen verlorenen Deal oder eine Rückerstattung. Der Zinssatz auf Vibe-Coded-Schulden ist variabel, und die Bank ruft zum ungünstigsten Zeitpunkt an.

Die 100-%-Neubau-Regel

Wir haben eine Regel für übernommene Vibe-Coded MVPs, die kein einziges Mal gebrochen wurde. Wir bauen sie von Grund auf neu.

Die Begründung ist kein Standesdünkel, sondern Arithmetik. Um eine Lovable-Codebase zu retten, müssen wir jede Datei lesen, die die KI geschrieben hat, das Datenmodell dokumentieren, das der Gründer nie gesehen hat, die useEffect-Kette entwirren, die Routen sichern, die Authentifizierung korrigieren und die Struktur in etwas umgestalten, das ein Mensch erweitern kann. Diese Arbeit ist ein vollständiger Neubau mit einer zusätzlichen Einschränkung: die Kunden nicht zu beschädigen, die die fehlerhafte Version bereits nutzen.

Ein sauberer Neubau auf unserem Stack dauert 3 bis 6 Wochen. Eine Sanierung dauert 8 bis 12 Wochen, weil jeder Bereinigungsschritt durch das bisherige Schema und die Live-Daten eingeschränkt ist. Die "Einsparungen" aus dem ursprünglichen Lovable-Projekt existieren nicht, sie wurden gegen die nächste Arbeitsrunde geliehen.

Ehrlich formuliert für einen Gründer: Das Lovable-Projekt hat die Validierung bezahlt. Es hat die ersten Kunden hereingebracht, und das ist echter Wert. Der Code selbst ist versunkener Aufwand. Das MVP beginnt jetzt.

Wie ein echtes MVP aussieht

Zum Vergleich: Hier ist ein Projekt, das wir in 6 Wochen für OHYP GmbH geliefert haben, einen Berliner Immobiliendienstleister, der Finanzierungszertifikate an Immobilienkäufer ausstellt.

Das Projekt ist eine Full-Stack-Plattform mit einem 10-Schritt-Finanzierungsformular als zentralem Konversionselement, einem Admin-Dashboard zur Verwaltung des Anfrage-Lifecycles und automatischer PDF-Zertifikatsgenerierung, die dem Kunden in unter 24 Stunden zugestellt wird. Der Stack besteht aus Next.js mit tRPC für End-to-End-Typsicherheit, Drizzle auf Neon Postgres und Better Auth für das Session-Management. Lighthouse-Performance-Score 96, Seitenladezeit unter 1,2 Sekunden, Festpreis.

Dieser Zeitrahmen ist kein Wunder. Rund 85 % jedes neuen Projekts auf unserem Stack sind Verbindungen, die bereits im vorherigen Projekt existieren, weil wir bei jedem Auftrag dieselbe Konfiguration aus Next.js 16, React 19, tRPC v11, Drizzle, Neon, Better Auth, Polar, AI SDK 6 über Vercel AI Gateway und Inngest verwenden. Die verbleibenden 15 % sind die Arbeit, die tatsächlich einzigartig für diesen Kunden ist: die Domänenlogik, das Datenmodell, die Workflows. KI-Tools beschleunigen diese 15 % innerhalb der bestehenden Struktur, sie ersetzen sie nicht.

Das ist die Version eines "KI-nativen MVPs", die den ersten zahlenden Kunden übersteht.

Wann Sie Lovable, Bolt oder v0 trotzdem nutzen sollten

Die Entscheidung lautet nicht "KI-Tools oder Ingenieure". Sie lautet: das richtige Werkzeug für die Phase, in der Sie sich befinden. Nutzen Sie Vibe-Coding für die Phasen, in denen es gewinnt. Beauftragen Sie Ingenieure für die Phasen, in denen es verliert.

Der ehrliche Weg für Gründer ist, den Prototypen mit Lovable zu veröffentlichen, zu validieren und dann Ingenieure einzustellen, bevor der erste zahlende Kunde eintrifft. Der Fehler besteht darin, "es funktioniert" allein die Arbeit über die Grenze tragen zu lassen.

Bei webvise führen wir MVP-Entwicklungen in 3 bis 5 Wochen auf demselben Stack durch, den wir für produktive SaaS-Projekte verwenden. Authentifizierung, Abrechnung, Admin und Observability sind von Tag eins an enthalten. Wenn Sie ein Vibe-Coded Projekt haben, das heute funktioniert, aber Widerstand leistet, teilen Sie uns mit, was Sie sehen, und wir sagen Ihnen, ob es eine Bereinigung oder ein Neubau ist. Bisher war die Antwort immer ein Neubau.