Lovable, Bolt, v0: Wenn Vibe-coded MVPs zur Tech-Debt-Hypothek werden

Vibe-coded Apps wie Lovable, Bolt und v0 sind hervorragend für Prototypen und katastrophal als Produktions-MVPs. Wer mir eines übergibt, bekommt einen vollständigen Neuaufbau: Struktur, Hooks und Auth zu bereinigen kostet mehr, als von vorn anzufangen. Dieser Beitrag zieht die Linie zwischen dem, was diese Tools leisten können, und dem, was sie nicht können.

Heute kann jeder coden. Ein Gründer ohne technischen Hintergrund beschreibt samstags ein SaaS auf Englisch und hat mittags etwas unter einer öffentlichen URL. Das ist eine echte Verschiebung, wie Software entsteht, und sie ist überwiegend positiv. Sie brachte aber auch ein neues Scheitermuster hervor, das vor zwei Jahren noch nicht existierte: Produktionsapps, die im eigenen Haus niemand lesen kann.

Jede Woche spreche ich mit Gründern, die einen Lovable-Build ausgeliefert haben, 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. Und dabei jede Architekturentscheidung getroffen, bevor der Gründer wusste, welche davon zählt.

Dieser Artikel schreibt Lovable, Bolt oder v0 nicht schlecht. Am Prototypen-Stadium haben sie ihren Platz. Er zieht die Grenze aus Kundenperspektive: was diese Tools ausliefern, was ein MVP braucht, um den ersten zahlenden Kunden zu überleben, und welches Muster sich in jeder Codebase zeigt, die ich übernehme.

• Vibe-Coding gewinnt in der Prototypenphase, wo Geschwindigkeit über Struktur steht und nichts an Kunden ausgeliefert wird.
• MVPs scheitern anders als Prototypen. Auth, Multi-Tenancy, ein Admin-Shell und Observability sind nicht verhandelbar, sobald ein echter Kunde eingeloggt ist.
• Der Bereinigungsaufwand ist der Neuaufbauaufwand. Jedes übernommene Vibe-coded MVP wird von Grund auf neu gebaut. Der Lovable-Build war versunkener Aufwand, keine eingesparte Zeit.
• Das Muster ist konsistent. Schlechte Struktur, useEffect-Missbrauch, unnötige Re-renders, offene Backend-Routen, fehlerhafte Auth, in dieser Reihenfolge.
• Lovable für das einsetzen, wofür es gemacht ist. Demos, interne Mockups, Ideenvalidierung. Ingenieure für alles, wofür ein Kunde zahlt.

Heute kann jeder coden (und das ist größtenteils gut so)

Die Hürde zu "Ich hab etwas gebaut" ist 2025 gefallen. v0 erzeugt eine Next.js-Komponente aus einem Screenshot, Lovable scaffoldet ein Supabase-Backend aus einem Absatz, Bolt baut eine deployed App in einem Chat, und Replit Agent läuft die ganze Schleife durch, bis etwas kompiliert.

Für Ideenvalidierung ist das ein echter Gewinn. Wer früher drei Wochen brauchte, um einen Freelancer zu finden, validiert dieselbe Idee jetzt in drei Stunden in echten Pixeln. Ein Designer baut das Demo für seinen Pitch, statt es in Figma zu mocken. Keiner dieser Anwendungsfälle braucht Produktionsdisziplin.

Probleme entstehen beim nächsten Schritt: wenn der Prototyp zum MVP umbenannt, einem zahlenden Kunden gezeigt und als Produktionssoftware behandelt wird. Die Tooling gibt keine Warnung, wenn diese Grenze überschritten wird. Der Gründer merkt es selten.

Prototyp-Grenze vs. MVP-Grenze

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

Der Prototyp fragt: Ergibt diese Idee in Pixeln Sinn? Er läuft lokal, scheitert laut und erreicht keine Nutzer. Das Scheitermuster lautet: "Ich sehe, dass etwas falsch ist, und korrigiere den Prompt." Er ist ein Lernartefakt, und die einzigen Betroffenen sind der Gründer und ein vertrauter Mitstreiter.

Ein MVP ist die erste Version, die zahlende Kunden anfassen. Sobald Geld oder persönliche Daten die Hand wechseln, ändert sich auch der implizite Vertrag. Der Kunde erwartet, dass sein Login funktioniert, seine Daten privat bleiben und die App seine Session nicht verliert, weil ein useEffect zweimal ausgeführt wurde. Das sind keine hohen Anforderungen, das ist die Mindestanforderung.

Vibe-coded Apps überschreiten diese Grenze meist lautlos, weil das Tool "production-ready" kommunizierte, während es einen Prototypen auslieferte. Die Kontrolle, die die Überschreitung erkennt, ist menschlich, nicht technisch: ein Gründer, der weiß, was ein MVP leisten muss, bevor er Geld nehmen darf.

Wenn die Grenze finanzielle Bedeutung hat, braucht es Ingenieure, keinen schnelleren Prompt. MVP-Builds laufen in einem festen Zeitfenster von 3 bis 5 Wochen, mit Auth, Billing, Admin-Shell und Observability von Anfang an.

Was sich in Vibe-coded Codebases tatsächlich findet

Wer mir ein Lovable- oder Bolt-Projekt zur Bereinigung übergibt: Das Muster ist so konsistent, dass ich weiß, was mich erwartet, bevor das Repo fertig geklont ist. Fünf Probleme, ungefähr in der Reihenfolge, in der sie schmerzen.

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

useEffect-Missbrauch. Jeder Fetch lebt in einem useEffect, jede Prop-Änderung löst einen Refetch aus, und Effects hängen von Objekten ab, die bei jedem Render neu erstellt werden. Die App bombardiert das Backend beim ersten Laden mit doppelten Anfragen, stagniert dann, wenn eine davon lautlos scheitert. Das Muster verschärft sich, sobald Formulare hinzukommen.

Unnötige Re-renders. Top-Level-State liegt in einem Context-Provider, der die gesamte App umschließt, also rendert jede Komponente bei jedem Tastendruck neu. Die App fühlt sich bei 10 Listeinträgen langsam und bei 100 unbrauchbar an. Die Lösung erfordert echtes React-Wissen, das der Prompt nie verlangt hat.

Offene Backend-Routen. Supabase-Tabellen mit deaktiviertem RLS oder "authenticated" ohne Row-Scoping, Server Actions, die einer client-seitig gesendeten user_id vertrauen, Edge Functions, die jede Payload akzeptieren, weil die Validierung im Formular lag. Ein Nutzer im Inkognito-Fenster kann jeden Datensatz in der Tabelle auslesen.

Fehlerhafte Auth. Session-Checks client-seitig, Rollenprüfungen per String-Vergleich gegen Felder, die die KI erfunden hat, Passwort-Reset-Flows mit identischem Token-Format für alle Nutzer, JWT-Secrets in der .env.example-Datei im öffentlichen Repo. Manchmal ist der Anon-Key das Einzige, was zwischen der App und "Ich bin jetzt Admin" steht.

Das sind keine Ausnahmen. Das ist das Median-Ergebnis von "KI hat das ohne Ingenieur im Loop geliefert", was ich aus technischer Perspektive in Warum KI-generierte Software trotzdem Engineering-Review braucht beschrieben habe.

"Es funktioniert" ist das gefährlichste Signal, dem man vertrauen kann

Vibe-coded Apps bestehen oft die erste Demo, und genau dort beginnt die Gefahr. Die Demo läuft, die ersten 10 Bekannten melden sich an, der erste Kunde zahlt, und der Gründer schließt daraus, dass der Build in Ordnung war.

Der Tech Debt wächst still, bis etwas ihn ans Licht zwingt. Die Auslöser sind vorhersehbar:

• Erster echter zahlender Kunde. Seine Daten überqueren die Autorisierungsgrenze. Die Grenze fehlt oder ist falsch. Man erfährt es durch ein Support-Ticket, nicht durch einen CI-Test.
• Erste Feature-Anfrage nach dem Launch. Das Datenmodell der KI ging von einem Nutzer pro Workspace aus. Der Kunde will zwei. Den zweiten Nutzer hinzuzufügen berührt 14 Dateien, die niemand je gelesen hat.
• Erstes Security-Review. Ein B2B-Interessent fragt nach SOC2-Dokumenten oder einem Pentest. Der Pentester findet die offenen Routen in 20 Minuten. Der Deal stockt oder platzt.
• Erster Admin-Bedarf. Der Gründer muss einen Kunden zurückerstatten, einen Bot sperren oder die Anmeldungen der letzten Woche einsehen. Eine Admin-Seite gibt es nicht, und eine hinzuzufügen erfordert, das Routing neu aufzubauen.
• Erstes Skalierungsereignis. Ein Blogbeitrag erscheint, der Traffic steigt, die App bricht zusammen, weil jedes Render jeden Datensatz abruft. Die Lösung ist das oben beschriebene Re-render-Problem.

Jeder dieser Auslöser verwandelt unsichtbare Schulden in einen Ausfall, einen verlorenen Deal oder eine Rückerstattung. Der Zinssatz auf Vibe-coded Debt ist variabel, und die Bank meldet sich zum denkbar schlechtesten Zeitpunkt.

Die 100%-Neuaufbau-Regel

Für übernommene Vibe-coded MVPs gilt eine Regel, die bisher keine Ausnahme hatte: Neuaufbau von Grund auf.

Die Begründung ist arithmetisch. Um einen Lovable-Codebase zu retten, muss jede Datei gelesen, das Datenmodell dokumentiert, das useEffect-Geflecht entwirrt, die Routen gesichert, die Auth korrigiert und die Struktur in etwas überführt werden, das ein Mensch erweitern kann. Das ist ein vollständiger Neuaufbau mit einer zusätzlichen Einschränkung: die Kunden, die bereits die fehlerhafte Version nutzen, dürfen nicht gestört werden.

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

Die ehrliche Einschätzung für einen Gründer: Der Lovable-Build hat die Validierung bezahlt. Er hat die ersten Kunden ins Haus geholt, und das ist echter Wert. Der Code selbst ist versunkener Aufwand. Das MVP beginnt jetzt.

Wie ein echtes MVP aussieht

Zum Vergleich: Ein Produktions-MVP für einen Immobiliendienstleister, der Finanzierungszertifikate für Immobilienkäufer ausstellt, wurde mit einem maßgeschneiderten Workflow gebaut, nicht mit einem Vibe-coded Scaffold.

Der Build ist eine Full-Stack-Plattform mit einem Finanzierungs-Workflow als zentralem Konversionselement, einem Admin-Dashboard zur Verwaltung des Anfrage-Lifecycles und automatisierter PDF-Zertifikatsgenerierung im versprochenen Servicefenster. Der Stack: Next.js mit tRPC für End-to-End-Typsicherheit, Drizzle auf Neon Postgres und Better Auth für das Session-Management. Der Vertrag nutzte ein Scoped-Delivery-Modell.

Dieser Zeitrahmen ist kein Zufall. Rund 85 % jedes neuen Projekts auf dem eigenen Stack ist Verkabelung, die aus dem vorherigen Projekt bereits existiert, weil auf jedem Engagement derselbe Setup aus Next.js 16, React 19, tRPC v11, Drizzle, Neon, Better Auth, Polar, AI SDK 6 via Vercel AI Gateway und Inngest zum Einsatz kommt. 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 MVP", die den ersten zahlenden Kunden übersteht.

Wann Lovable, Bolt oder v0 trotzdem die richtige Wahl sind

Das Tool nach Phase wählen: Vibe-Coding für Demos und Exploration, Ingenieure für bezahlte Produktpfade.

Der kluge Gründerzug: den Prototyp auf Lovable ausliefern, validieren, dann Ingenieure engagieren, bevor der erste zahlende Kunde eintrifft. Der Fehler ist, "es funktioniert" die Arbeit über die Grenze tragen zu lassen.

webvise realisiert MVP-Builds in 3 bis 5 Wochen auf demselben Stack, der für Produktions-SaaS eingesetzt wird. Auth, Billing, Admin und Observability sind von Tag eins im Paket. Bei einem Vibe-coded Build, der heute funktioniert, aber zunehmend Widerstand leistet: beschreiben Sie, was Sie sehen, und Sie erhalten eine klare Einschätzung, ob Bereinigung oder Neuaufbau die richtige Antwort ist. Bisher war die Antwort immer Neuaufbau.