Lovable-App funktioniert nicht mehr? Der ehrliche Notfall-Guide
Gestern lief noch alles, heute bricht bei jedem Klick etwas, und der KI-Agent macht es nur schlimmer. Hier steht, was hinter den typischen Fehlern steckt, was Revert und „Try to fix“ wirklich tun und wann Reparatur günstiger ist als Neubau.
Wenn eine Lovable-App plötzlich nicht mehr funktioniert, liegt es selten an einem einzelnen Bug, sondern an der Basis: Die KI baut schnell sichtbare Features, aber ohne stabile Architektur, Zugriffsschutz und Tests. Erste Hilfe: nicht weiter-prompten, zur letzten funktionierenden Version zurückspringen (das stellt nur Code wieder her, keine Datenbank-Daten) und den Fehler im Chat- oder Plan-Modus untersuchen lassen, bevor Code geändert wird. Was wirklich kaputt ist, zeigt der kostenlose decivo Scan in wenigen Minuten.
Das Wichtigste zuerst
- Weiter-prompten macht es oft schlimmer: Der KI-Agent baut dieselbe Stelle neu, statt die Ursache zu finden.
- Revert ist euer Sicherheitsnetz, aber nur für Code. Laut Lovable-Doku werden Datenbank-Daten nicht zurückgesetzt und verbrauchte Credits nicht erstattet.
- „Try to fix“ ist bis zu zehnmal kostenlos (geteilt mit dem Security-View, je 24 Stunden wieder frei), danach kostet es Credits.
- Leere Listen ohne Fehlermeldung haben oft dieselbe Ursache: Row Level Security ist an, aber es fehlt eine Regel, die das Lesen erlaubt.
- Eigene Daten aus dem KI-App-Radar (Oktober 2026): Bei 25 % (98 von 392) der Apps ist schon der erste Seitenaufruf schwer, 25 % (112 von 454) rendern ihren Inhalt nur im Browser. Von den Lovable-Apps bekamen 25 % (47 von 187) ein Go.
- Ob Rettung oder Neubau günstiger ist, entscheidet der tatsächliche Zustand, nicht das Bauchgefühl. Der kostenlose Scan liefert die Faktenbasis.
Warum eine Lovable-App irgendwann bricht
Lovable, Bolt und Co. sind darin brillant, in Stunden etwas Sichtbares zu bauen: ein Login, ein Dashboard, eine Datenbank. Was sie nicht mitliefern, ist das Unsichtbare, das eine App tragfähig macht: eine durchdachte Architektur, sauberer Zugriffsschutz und Tests. Vibe Coding heißt: Man akzeptiert die Vorschläge der KI und liest den Code nicht mehr im Detail. Das funktioniert erstaunlich gut, für die ersten Tage. Mehr dazu im Glossar zu Vibe Coding.
Dann kippt es. Jedes neue Feature verändert Stellen, die vorher liefen, weil die KI keine stabile Struktur hat, an der sie sich festhält. Der Code wächst schneller, als irgendjemand ihn versteht. GitClear misst seit dem Aufkommen von KI-Assistenten mehr kopierten Code (von 8,3 % auf 12,3 % der geänderten Zeilen) und immer weniger Aufräumarbeit (verschobene Zeilen von 25 % auf unter 10 %). Ab einem gewissen Punkt reißt jede Änderung zwei andere auf.
Das ist kein Versagen von euch. Es ist der eingebaute Preis von Geschwindigkeit ohne Kontrolle. Die gute Nachricht: Der Zustand ist messbar und in den meisten Fällen rettbar. Warum KI-Code selten von allein produktionsreif ist, haben wir mit Studien und einem eigenen Audit belegt: Ist KI-Code produktionsreif?
Typische Lovable-Fehler und was dahintersteckt
Die meisten Notfälle sehen unterschiedlich aus, haben aber eine Handvoll Ursachen. Diese Tabelle hilft beim Einordnen, bevor ihr den nächsten Prompt schreibt.
| Symptom | Häufige Ursache | Erster Schritt |
|---|---|---|
| Weißer Bildschirm nach einer Änderung | Laufzeitfehler im Frontend, oft eine fehlende Variable oder ein umbenannter Import | Browser-Konsole öffnen (Rechtsklick, Untersuchen), rote Fehlermeldung kopieren, letzte Version wiederherstellen |
| Listen bleiben leer, Speichern scheitert still | Row Level Security ist an, aber keine Regel erlaubt Lesen oder Schreiben | In Supabase die Regeln der Tabelle prüfen; beim Speichern meldet Supabase oft „violates row-level security policy“ |
| Login klappt lokal, aber nicht auf der eigenen Domain | Die Domain fehlt in den erlaubten Weiterleitungs-Adressen der Anmeldung | In Supabase unter Authentication die Site URL und die Redirect URLs um die neue Domain ergänzen |
| Unterseite liefert nach dem Neuladen 404 | Single-Page-App auf einem Hosting ohne Weiterleitung aller Pfade auf die Startdatei | Beim Hoster eine Rewrite-Regel auf index.html anlegen |
| Jede Reparatur bricht etwas Neues | Fehlende Struktur: Logik ist kopiert und über viele Dateien verteilt | Nicht weiter-prompten, im Chat-Modus die Ursache erklären lassen, Zustand von außen prüfen |
| App ist spürbar langsam | Sehr großes JavaScript-Bundle, alles wird erst im Browser zusammengebaut | Ersten Seitenaufruf messen (z. B. Lighthouse), große Bibliotheken und Bilder prüfen |
Die Tabelle ersetzt keine Diagnose. Sie zeigt, wo ihr zuerst hinschauen solltet.
Zwei Zeilen davon sehen wir im KI-App-Radar ständig. Bei 25 % (98 von 392) der geprüften Apps ist schon der erste Seitenaufruf schwer, 14 % (62 von 454) liefern ein sehr großes JavaScript-Bundle aus, und 25 % (112 von 454) bauen ihren Inhalt nur im Browser zusammen. Das macht die App langsam und für Suchmaschinen schwer lesbar. Dazu antworten 72 % (325 von 454) auf Adressen, die es gar nicht gibt, mit einer normalen Seite statt mit einem Fehler (Lauf „Panel 2026-10-01“, 454 Apps mit DACH-Bezug).
Die 5 Warnzeichen hinter den Fehlern
1. Jedes neue Feature bricht zwei alte. Der Code läuft, aber eine Änderung an einer Stelle reißt Dinge auf, die vorher funktionierten. Das ist das klassische Zeichen fehlender Architektur: Es gibt keine klaren Grenzen zwischen den Teilen der App.
2. Der KI-Agent dreht sich im Kreis. Ihr erklärt dasselbe Problem zum dritten Mal, bekommt jedes Mal eine neue Variante und wisst am Ende nicht, welche davon richtig ist. Die KI rät, statt die Ursache zu verstehen.
3. Ihr traut euch nicht mehr, live zu gehen. Nicht aus Zögern, sondern weil niemand mehr weiß, was beim nächsten Update kaputtgeht. Fehlende Tests machen jede Veröffentlichung zum Glücksspiel.
4. Login, Bezahlung oder Daten spinnen. Genau die Stellen, die Zugriffsschutz brauchen, sind bei KI-Code am schwächsten. In unserem Audit wurde keine einzige der geprüften Autorisierungs-Kontrollen erfüllt.
5. Irgendetwas fühlt sich unsicher an. Oft zu Recht: Schlüssel im Browser sichtbar, Datenbank ohne Schutz, .env-Datei öffentlich. Das sind die teuersten Fehler, und sie sind von außen prüfbar.
Erste Hilfe: Revert, Chat-Modus und Try to fix richtig nutzen
Nicht blind weiter-prompten. Der häufigste Fehler in Panik: der KI noch zehnmal „reparier das“ zurufen. Jeder Durchlauf verändert mehr Code, und der Schaden wächst.
Zur letzten funktionierenden Version zurück. Lovable legt bei jeder Änderung automatisch eine Version an; in der Versionshistorie springt ihr zurück. Drei Dinge stehen dazu in der Lovable-Doku: Revert stellt nur den Code wieder her, Daten in der Datenbank bleiben, wie sie sind. Verbrauchte Credits werden nicht erstattet. Und sehr alte Versionen lassen sich ansehen, aber nicht mehr wiederherstellen. Wer zusätzlich GitHub verbunden hat, hat eine zweite, unabhängige Sicherung.
Erst untersuchen, dann ändern. Im Chat-Modus untersucht Lovable ein Problem, ohne Code zu ändern; der Plan-Modus schreibt einen Plan, den ihr freigebt, bevor gebaut wird. Beschreibt, was ihr seht und was ihr erwartet habt, und bittet ausdrücklich darum, die Ursache zu finden, bevor etwas geändert wird.
„Try to fix“ gezielt einsetzen. Laut Lovable sind zehn Fixes kostenlos, geteilt zwischen „Try to fix“ und dem Security-View; jeder kostenlose Fix ist 24 Stunden nach Nutzung wieder verfügbar. Danach verbraucht „Try to fix“ Credits wie normales Bauen. Einmal versuchen ist sinnvoll, fünfmal hintereinander meist nicht.
Neutralen Blick von außen holen. Bevor ihr Zeit oder Geld in Reparaturen steckt, braucht ihr Fakten: Was ist wirklich kaputt, was nur Symptom, und wie tief sitzt es? Genau das liefert der kostenlose decivo Scan in Minuten, ohne dass ihr Zugang zu eurem Code gebt.
Was ihr in 5 Minuten selbst prüfen könnt
Ihr müsst kein Entwickler sein, um die gefährlichsten Probleme zu erkennen. Öffnet eure App im Browser, klickt mit der rechten Maustaste auf „Untersuchen“ und schaut in die Reiter „Netzwerk“ und „Konsole“. Tauchen dort rote Fehler oder lange Schlüssel auf, ist das ein Warnsignal.
Noch einfacher: Gebt eure öffentliche URL in den decivo Scan ein. Er prüft von außen sichtbare Signale in Sicherheit (z. B. im Browser lesbare Datenbank-Schlüssel, offene .env-Dateien), Aufbau, Datenschutz und Code-Sauberkeit und liefert ein klares Go, Iterate oder Stop mit Erklärung.
Das kostet nichts, dauert Minuten, und ihr gebt keinen Zugang zu Code oder Datenbank. Für eine tiefere Prüfung (Zugriffsschutz der Datenbank, Schnittstellen, veraltete Bausteine) verbindet ihr optional euer GitHub-Projekt mit reinem Lesezugriff, ebenfalls kostenlos. Was ein Lovable-Projekt für den Launch braucht, zeigt die Seite Ist eure Lovable-App produktionsreif?
Der unsichtbare Teil: Sicherheit und Daten
Das Gefährlichste an einer wackelnden KI-App sieht man nicht im Betrieb, es sind offene Daten. In unserem KI-App-Radar schreiben 24 % (109 von 454) der Apps direkt aus dem Browser in die Datenbank. Dann trägt allein Row Level Security den Schutz, und genau die fehlt bei KI-gebauten Apps am häufigsten.
Wie das aussieht, zeigt eine dokumentierte Lücke in Lovable-Apps (CVE-2025-48757): Der Sicherheitsforscher Matt Palmer fand bei 170 von 1.645 gescannten Projekten unzureichende Row-Level-Security-Regeln, betroffen waren 303 Endpunkte. Lovable bestreitet die CVE mit dem Hinweis, dass jeder Kunde für den Schutz seiner Daten verantwortlich ist. Eine breitere Untersuchung von 1.072 KI-gebauten Apps fand bei 98 % mindestens eine Lücke, bei 16 % eine kritische (Symbiotic Security). Im DACH-Raum kostet so etwas nicht nur Vertrauen, sondern kann eine Meldepflicht nach DSGVO auslösen.
Unser eigener Vibe-Code-Audit bestätigt das Muster: Über 12 typische MVP-Features hinweg wurde keine einzige Autorisierungs-Kontrolle erfüllt und kein einziger Test geschrieben. Welche Lücken am häufigsten sind und wie ihr Row Level Security in zwei Minuten selbst prüft, steht in Ist eure Lovable-App sicher?
Retten oder neu bauen?
Nicht jede kaputte App muss neu gebaut werden, und nicht jede lässt sich wirtschaftlich retten. Zur Einordnung: Von den Lovable-Apps im KI-App-Radar bekamen 25 % (47 von 187) ein Go und 75 % (140 von 187) ein Iterate, also „nachbessern“. Kein einziges Stop. Die meisten Lovable-Apps sind reparierbar.
Grobe Faustregel: Ist das Fundament in Ordnung (klare Datenmodelle, halbwegs saubere Struktur) und brennt es nur an einzelnen Stellen, ist Rettung meist der günstigere Weg. Sind Zugriffsschutz, Datenmodell und Architektur grundlegend offen, kann ein gezielter Neuaufbau auf dem, was schon funktioniert, am Ende billiger sein als endloses Flicken. Mehr dazu: Vom Prototyp zum Produkt und Lovable-Alternativen.
Der Scan empfiehlt euch auf Basis der Befunde einen Weg, mit Preis vorab: die Sofort-Absicherung (540 € netto, Festpreis, schließt alle offenen Lücken hoher Schwere), den Reparaturplan (349 € netto, jede Fundstelle mit Reihenfolge zum Selbermachen), Reparatur und Stabilisierung (ab 1.090 €, Festpreis aus eurem Scan, verbindlich nach dem Repository-Scan) oder den Neubau ab 12.500 €. Details stehen bei Vibe Code Rescue; wenn ihr die App dauerhaft weiterentwickeln lassen wollt, bei Lovable-App weiterentwickeln lassen. Was ein Neubau typischerweise kostet, rechnet der MVP-Kostenrechner durch.
Quellen
Alle Zahlen und Produkt-Aussagen in diesem Artikel stammen aus den folgenden Quellen. Abgerufen am 20. Oktober 2026.
- decivo — KI-App-Radar DACH, Lauf „Panel 2026-10-01“, Methodik 2026.33 (CC BY 4.0)
- Lovable Docs — Revert and restore your project with version history
- Lovable Docs — FAQ (Try to fix, Plan mode, Chat mode)
- Supabase Docs — Row Level Security
- Supabase Docs — Redirect URLs (Auth)
- NVD — CVE-2025-48757: unzureichende Row-Level-Security-Policies in Lovable (vom Anbieter bestritten)
- Matt Palmer — Statement on CVE-2025-48757 (170 von 1.645 Projekten, 303 Endpunkte)
- Symbiotic Security — „We Scanned 1,072 Vibe Coded Apps, 98% Had Security Flaws“ (Juni 2026)
- decivo Vibe-Code-Audit v1.0 (2026), CC BY 4.0
- GitClear — AI Copilot Code Quality 2025 (Code-Duplikate & Refactoring)
Eine Lovable-App, die nicht mehr funktioniert, ist kein verlorenes Projekt. Meistens fehlt nur der ehrliche Blick auf das, was unter der Oberfläche liegt.
Jetzt kostenlos scannenLovable-App reparieren: die wichtigsten Fragen
Warum funktioniert meine Lovable-App plötzlich nicht mehr?
Meist liegt es nicht an einem einzelnen Bug, sondern an fehlender Struktur: Die KI baut neue Features ohne stabile Architektur, an der sie sich festhält. Ab einem gewissen Punkt verändert jede Änderung Stellen, die vorher liefen. Typische Auslöser sind Laufzeitfehler im Frontend, fehlende Row-Level-Security-Regeln und falsche Weiterleitungs-Adressen beim Login.
Stellt ein Revert in Lovable auch die Datenbank wieder her?
Nein. Laut Lovable-Doku stellt ein Revert nur den Code wieder her; Daten in der Datenbank, die nach dieser Version geändert wurden, bleiben unverändert. Verbrauchte Credits werden nicht erstattet, und sehr alte Versionen lassen sich nur noch ansehen, nicht wiederherstellen.
Kostet „Try to fix“ in Lovable Credits?
Zunächst nicht. Laut Lovable sind zehn Fixes kostenlos, geteilt zwischen „Try to fix“ und dem Security-View, und jeder kostenlose Fix ist 24 Stunden nach Nutzung wieder verfügbar. Danach verbraucht „Try to fix“ Credits wie normales Bauen. Bei wiederkehrenden Fehlern empfiehlt Lovable den Chat- oder Plan-Modus, um erst die Ursache zu untersuchen.
Warum werden in meiner Lovable-App keine Daten gespeichert?
Sehr häufig wegen Row Level Security: Ist RLS auf einer Tabelle aktiv, aber keine Regel erlaubt Lesen oder Schreiben, liefert Supabase leere Listen oder lehnt das Speichern ab. Die Lösung ist eine passende Regel, die an die Nutzer-ID gebunden ist, nicht das Abschalten von RLS.
Kann man eine kaputte Vibe-Coded-App überhaupt retten?
Meistens ja. Wenn das Fundament in Ordnung ist und nur einzelne Stellen brennen, ist Rettung der günstigere Weg. Sind Datenmodell und Zugriffsschutz grundlegend offen, kann ein gezielter Neuaufbau günstiger sein. Der kostenlose Scan liefert die Faktenbasis für diese Entscheidung.
Was kostet es, eine Lovable-App reparieren zu lassen?
Der Scan ist kostenlos. Danach hängt es vom Weg ab: Sofort-Absicherung 540 € netto (Festpreis), Reparaturplan 349 € netto, Reparatur und Stabilisierung ab 1.090 € als Festpreis aus eurem Scan, verbindlich nach dem Repository-Scan. Welcher Weg passt, empfiehlt das Scan-Ergebnis.
Passende Artikel
- Vibe Code Rescue
Ist Lovable DSGVO-konform? AVV, Serverstandort, Pflichten
Lovable bindet den AVV an Business und Enterprise, Lovable Cloud speichert in der gewählten Region — KI-Anfragen nicht. Was Supabase, Base44 und Bolt anders machen, welche Pflichten eure App selbst hat (Impressum, Art. 13, § 25 TDDDG, KI-VO Art. 50, BFSG) eine Checkliste mit 12 Punkten und eigene Zahlen aus 454 KI-Apps im DACH-Raum.
- Vibe Code Rescue
Lovable-App sicher? Die 5 häufigsten Sicherheitslücken 2026
Die 5 häufigsten Lücken in Lovable-Apps laienverständlich erklärt: wo der Supabase service_role-Key liegt, wie ihr Row Level Security in 2 Minuten prüft, welche Sicherheitsvorfälle rund um Lovable öffentlich wurden und was wir bei 454 KI-Apps aus dem DACH-Raum messen.
- KI-Codequalität
Ist KI-Code produktionsreif? Was die Studien 2026 sagen
Eigene Studie: 12 MVP-Features per naivem Prompt erfüllen im Chat-Coding nur 19,6 %, mit dem neuesten Agenten (Codex) 47,1 % der Produktionsreife-Kontrollen — 0 von 12 fertig. Plus alle großen Studien 2026 (Veracode, GitClear, METR, CodeRabbit), Felddaten aus 454 live KI-Apps und der Weiterbau-Test mit 5 Fragen.
Prüft, ob eure App noch zu retten ist.
Der kostenlose decivo Scan zeigt in Minuten, was wirklich kaputt ist, und ob Reparatur oder Neubau günstiger ist.
Kostenlos · kein Code-Zugang nötig · Ergebnis in Minuten.