Lovable-App production-ready machen: die Checkliste

Eine Lovable-App ist production-ready, wenn drei Dinge nachweislich stimmen: Jede Tabelle in Supabase ist per Row Level Security geschützt und mit echten Rollen getestet, keine geheimen Schlüssel liegen im Frontend, und es gibt einen geregelten Betrieb mit Backups, Staging und jemandem, der den Code verantwortet. Lovable bringt Sie erstaunlich schnell zu einer App, die funktioniert. Ob sie auch sicher ist, sagt Ihnen das Tool nicht verlässlich. Dieser Beitrag zeigt, was Lovable gut macht, wo die typischen Lücken liegen und mit welcher Checkliste Sie Ihre Lovable-App vor dem Go-live prüfen.

Wir sprechen dabei aus der Praxis. Wir haben Lovable-Apps und andere per Vibe Coding gebaute Anwendungen vor dem Rollout geprüft und nachgehärtet. Die Beispiele in diesem Beitrag stammen aus diesen Projekten.

Was ist eine Lovable-App überhaupt?

Lovable ist ein KI-App-Builder aus Stockholm. Sie beschreiben im Chat, was Ihre Anwendung können soll, und Lovable erzeugt daraus eine komplette Web-App: Oberfläche in React, Datenbank, Login, Dateiablage und Hosting. Im Hintergrund arbeitet fast immer Supabase, entweder als eigenes Supabase-Projekt, das Sie verbinden, oder als Lovable Cloud, bei der Lovable die Supabase-Instanz für Sie verwaltet.

Für Unternehmen ist das ein echter Fortschritt. Fachabteilungen bauen in Tagen ein internes Tool, ein Kundenportal oder einen klickbaren Prototyp, ohne auf ein IT-Projekt zu warten. Wir sehen Lovable-Apps, die mehrere Mandanten verwalten, Dokumente speichern und Zahlungen abwickeln. Das ist kein Spielzeug mehr.

Gerade deshalb lohnt sich der nüchterne Blick. Lovable optimiert darauf, dass die App funktioniert. Ob jede Datenbankregel stimmt, ob ein Nutzer über die Schnittstelle an fremde Daten kommt oder ob ein Schlüssel im ausgelieferten JavaScript steht, sehen Sie in der Vorschau nicht. Funktionierender, aber unsicherer Code sieht genauso fertig aus wie sicherer Code.

Wo sind Lovable-Apps typischerweise verwundbar?

Die meisten Probleme, die wir finden, sind nicht Lovable-spezifisch, sondern typisch für den Stack aus Frontend und direkt angesprochener Datenbank. Lovable macht es nur besonders leicht, diesen Stack aufzubauen, ohne die Regeln dahinter zu kennen.

Fehlende oder zu weite Row Level Security. In einer Lovable-App fragt der Browser die Datenbank direkt ab, mit einem öffentlichen Schlüssel. Das ist so gewollt. Sicher ist es nur, wenn für jede Tabelle Row Level Security (RLS) aktiv ist und die Regeln genau festlegen, wer welche Zeile lesen und ändern darf. Fehlt eine Regel oder lautet sie sinngemäß „alle eingeloggten Nutzer dürfen alles“, kann jeder Nutzer fremde Datensätze abfragen. Wie real das ist, zeigte 2025 die Schwachstelle CVE-2025-48757: Bei über 170 Lovable-Projekten ließen sich Tabellen ohne Login auslesen.

Mandantentrennung nur in der Oberfläche. Viele Apps zeigen jedem Kunden in der Oberfläche nur seine eigenen Daten. Die Filterung passiert aber im Frontend. Wer die Anfrage im Browser leicht verändert, sieht die Daten anderer Mandanten. Entscheidend ist, was die Datenbank herausgibt, nicht was die Oberfläche anzeigt.

Secrets im Frontend. Ein Schlüssel für einen Zahlungsdienst, einen E-Mail-Versand oder ein KI-Modell landet schnell im Client-Code, weil es so am schnellsten funktioniert. Alles, was im Browser ankommt, kann jeder lesen. Solche Schlüssel gehören in Edge Functions und Umgebungsvariablen, nie ins Frontend. Besonders kritisch ist der Supabase-Service-Key, der RLS komplett umgeht.

Offene Dateiablage. Dokumente, Bilder oder Videos liegen in Storage-Buckets. Ist ein Bucket öffentlich oder fehlen die Regeln, sind die Dateien über ihre Adresse abrufbar, auch ohne Login.

Edge Functions ohne Prüfung. Serverfunktionen, die Lovable für Webhooks oder externe Dienste anlegt, prüfen nicht immer, wer sie aufruft. Ein Webhook ohne Signaturprüfung nimmt im Zweifel auch gefälschte Zahlungsbestätigungen an.

Eine ausführliche Liste der häufigsten Schwachstellen in KI-gebauter Software, unabhängig vom Tool, finden Sie in unserem Beitrag Vibe Coding in Produktion bringen.

Reicht der Lovable-Sicherheitsscan aus?

Lovable hat nachgelegt. Es gibt einen eingebauten Sicherheitsscan, der vor dem Veröffentlichen auf fehlende RLS-Regeln und bekannte Probleme in Abhängigkeiten hinweist (Stand Oktober 2026). Das ist sinnvoll, und Sie sollten jede Warnung ernst nehmen.

Ersetzen kann der Scan eine Prüfung trotzdem nicht. Er erkennt, ob eine Regel existiert, aber nicht, ob sie fachlich richtig ist. Eine Policy, die allen eingeloggten Nutzern Zugriff auf alle Kundendatensätze gibt, ist technisch vorhanden und trotzdem eine Datenpanne. Ob Rolle A wirklich nur ihre Daten sieht, lässt sich nur prüfen, indem man es mit echten Anmeldungen für jede Rolle ausprobiert, inklusive bewusster Umgehungsversuche direkt an der Schnittstelle.

Unsere Faustregel: Der Scan ist der Rauchmelder, nicht die Brandschutzbegehung. Er gehört zur Grundausstattung, aber bevor sensible Daten in die App fließen, schaut jemand mit Erfahrung auf das Rechtemodell.

Die Checkliste: Ist Ihre Lovable-App production-ready?

Diese Punkte prüfen wir bei jeder Lovable-App vor dem Go-live. Sie sind nach Wichtigkeit sortiert. Die ersten fünf sind Pflicht, sobald personenbezogene Daten oder mehrere Nutzergruppen im Spiel sind.

1. RLS auf jeder Tabelle aktiv. Keine Ausnahme, auch nicht für Hilfstabellen.
2. Policies fachlich geprüft. Jede Regel beantwortet die Frage: Darf genau dieser Nutzer genau diese Zeile sehen oder ändern?
3. Rollentests mit echten Anmeldungen. Testnutzer je Rolle versuchen, über die Schnittstelle an fremde Daten zu kommen. Bei Mandanten: Kunde A versucht, Daten von Kunde B zu lesen.
4. Keine Secrets im Frontend. Code und Versionshistorie nach Schlüsseln durchsuchen. Alles Geheime in Edge Functions und Umgebungsvariablen.
5. Storage-Buckets abgesichert. Private Buckets, Zugriffsregeln wie bei Tabellen, signierte Links mit Ablaufzeit.
6. Edge Functions authentifiziert. Jede Funktion prüft den Aufrufer, Webhooks prüfen die Signatur.
7. Login sauber konfiguriert. E-Mail-Bestätigung, sinnvolle Passwortregeln, Weiterleitungsadressen nur auf die eigene Domain.
8. Code in GitHub. Die GitHub-Synchronisation ist aktiv, damit Sie jederzeit eine Kopie des Codes und eine nachvollziehbare Historie haben.
9. Backups und Wiederherstellung getestet. Nicht nur vorhanden, sondern einmal tatsächlich zurückgespielt.
10. Staging-Umgebung. Änderungen landen erst in einer Testumgebung, bevor sie die Produktivdaten berühren.
11. Monitoring und Fehlermeldungen. Jemand merkt, wenn etwas kaputtgeht, bevor es die Nutzer melden.
12. Datenschutz geklärt. Serverstandort, Auftragsverarbeitung und Löschkonzept sind dokumentiert.

Wenn Sie bei den ersten fünf Punkten nicht sicher Ja sagen können, ist die App noch nicht bereit für echte Kundendaten. Das ist keine Schande, sondern der normale Stand einer Vibe-Coding-App nach der Bauphase.

Lovable Cloud oder eigenes Supabase-Projekt?

Diese Frage entscheidet mehr über den späteren Betrieb, als viele beim Start ahnen. Lovable Cloud ist bequem: Datenbank, Login und Dateiablage sind sofort da, ohne eigenes Konto bei Supabase. Der Preis dafür ist weniger Kontrolle. Die verwaltete Instanz taucht nicht in einem eigenen Supabase-Dashboard auf, und gewohnte Werkzeuge für Backups, Logs oder Datenbankzugriff stehen nur eingeschränkt zur Verfügung. Der Umzug in ein eigenes Supabase-Projekt ist möglich, laut Lovable-Dokumentation aber mit Handarbeit verbunden, etwa beim Export der Tabellen und beim Neueinrichten der Login-Anbieter.

Ein eigenes Supabase-Projekt verlangt am Anfang etwas mehr Einrichtung. Dafür wählen Sie die Region selbst, etwa Frankfurt, haben direkten Zugriff auf Datenbank, Backups und Logs und können später Entwickler oder einen Dienstleister hinzuziehen, ohne erst umziehen zu müssen.

Unsere Empfehlung: Für Prototypen und Demos ist Lovable Cloud völlig in Ordnung. Sobald klar ist, dass die App produktiv geht und personenbezogene Daten verarbeitet, verbinden Sie ein eigenes Supabase-Projekt in einer EU-Region. Je früher, desto kleiner der Umzug.

Weiter mit Lovable oder Export in eigenen Betrieb?

Production-ready heißt nicht automatisch, dass Sie Lovable verlassen müssen. Es gibt drei realistische Wege, und welcher passt, hängt davon ab, wie kritisch die App ist und wer sie weiterentwickelt.

Nur Lovable passt für Prototypen, Demos und Werkzeuge ohne sensible Daten. Hier zählt Tempo, und der eingebaute Scan reicht als Grundschutz.

Lovable mit Review ist der häufigste Fall in unseren Projekten. Die Fachabteilung baut weiter in Lovable, aber Rechtemodell, Datenbankregeln und Schnittstellen werden einmal strukturiert geprüft und bei größeren Änderungen erneut. Dazu kommen Backups, Monitoring und klare Regeln, was ohne Review live gehen darf.

Export in eigenen Betrieb lohnt sich, wenn die App zum Kernprozess wird, viele Nutzer hat oder Anforderungen entstehen, die im Chat schwer umzusetzen sind. Über die GitHub-Synchronisation gehört Ihnen der Code ohnehin. Ein Entwicklungsteam übernimmt ihn, setzt CI/CD, Staging und Tests auf und entwickelt mit Coding-Agenten wie Claude Code oder Cursor weiter. Die Lovable-Oberfläche bleibt dabei oft als Startpunkt erhalten.

Ein Neubau ist dagegen fast nie nötig. Der Code, den Lovable erzeugt, ist gängiges React mit TypeScript und Supabase, also ein Stack, mit dem jedes moderne Entwicklungsteam arbeiten kann.

Praxisbeispiel: Security-Audit einer Lovable-App bei 123-MPU

Wie das konkret aussieht, zeigt unser Projekt mit 123-MPU. Das Unternehmen bereitet Menschen auf die Medizinisch-Psychologische Untersuchung vor und hat mit Lovable und Supabase eine eigene Plattform für das Klientenmanagement gebaut. Die App verwaltet mehrere Mandanten und verarbeitet sehr sensible personenbezogene Daten, darunter Dokumente und Videoaufzeichnungen.

Vor dem Go-live standen genau die Fragen, die sich jeder stellen sollte: Ist die Trennung zwischen den Mandanten dicht? Greifen die RLS-Regeln wirklich, oder existieren sie nur auf dem Papier? Was passiert, wenn die Nutzerzahl wächst?

Wir haben die Plattform mit 25 Testfällen geprüft: Cross-Tenant-Zugriffe gegen die RLS-Regeln, Secrets und Schlüssel, Login und Magic Links, Zugriff auf Dateien und Videos, dazu die Sicherheit der angebundenen Schnittstellen inklusive Webhooks. Das Ergebnis war typisch für eine gut gebaute Lovable-App. Der Großteil der Tests war bestanden. Zwei kritische Lücken haben wir vor dem Go-live gefunden und dokumentiert, zusammen mit einem Threat Model und einem priorisierten Maßnahmenplan in fünf Phasen bis zur „Ship-Ready“-Plattform.

Der wichtigste Befund war aber ein wirtschaftlicher: Die App musste nicht neu gebaut werden. Nach unserer Schätzung dauert das Nachhärten Tage, eine Neuentwicklung hätte zwei bis vier Monate gekostet. Ein ähnliches Muster haben wir bei Upland Parcs gesehen, wo ein per Vibe Coding gebautes Intranet nach dem Security-Check und wenigen gezielten Fixes für das ganze Team freigegeben wurde.

Was kostet es, eine Lovable-App production-ready zu machen?

Die Kosten bestehen aus zwei Teilen: dem laufenden Lovable-Abo und dem einmaligen Aufwand für Prüfung und Nachhärtung.

Lovable selbst rechnet über Credits ab, die Pläne beginnen bei rund 25 US-Dollar pro Monat für Pro (Stand Oktober 2026). Für den Produktivbetrieb kommen Kosten für Supabase, die eigene Domain und gegebenenfalls KI-Aufrufe in der App dazu. Behalten Sie den Credit-Verbrauch im Blick: Eine Funktion, an der die KI immer wieder scheitert, kann viele Credits kosten, ohne dass die App besser wird. Spätestens dann lohnt sich ein Entwickler, der gezielt eingreift.

Der Aufwand für die Prüfung hängt von Datenmodell, Anzahl der Rollen und Schnittstellen ab. Eine interne App mit zwei Rollen ist schnell geprüft, eine Mandanten-Plattform mit Zahlungen und Dokumenten deutlich aufwendiger. Nach unserer Erfahrung liegt ein Security-Check mit Nachhärtung bei einem Bruchteil dessen, was ein Neubau kosten würde. Wie wir solche Checks und die anschließende Begleitung anbieten, finden Sie auf der Seite Services.

Was gilt beim Datenschutz für Lovable-Apps?

Sobald Ihre App personenbezogene Daten verarbeitet, gelten die üblichen Pflichten aus der DSGVO. Drei Fragen sollten Sie vor dem Go-live beantworten können:

• Wo liegen die Daten? Bei einem eigenen Supabase-Projekt wählen Sie die Region selbst. Bei Lovable Cloud prüfen Sie die aktuellen Angaben von Lovable.
• Gibt es Verträge zur Auftragsverarbeitung? Mit Lovable, mit Supabase und mit jedem weiteren Dienst, der personenbezogene Daten sieht, etwa für E-Mail-Versand oder KI-Modelle.
• Können Sie Auskunft und Löschung umsetzen? Wenn ein Nutzer seine Daten anfordert oder gelöscht haben will, muss das technisch gehen, inklusive Dateien und Backups.

Eine offene Tabelle mit Kundendaten ist in Deutschland nicht nur ein technischer Fehler, sondern potenziell eine meldepflichtige Datenschutzverletzung. Auch deshalb gehört die RLS-Prüfung an den Anfang der Checkliste und nicht ans Ende.

Fazit: Lovable bringt Sie weit, den letzten Schritt gehen Sie bewusst

Lovable ist eines der besten Werkzeuge, um aus einer Idee schnell eine funktionierende App zu machen. Für Prototypen, interne Tools und erste Kundenportale nutzen wir es selbst gern als Startpunkt. Die Grenze liegt nicht im Bauen, sondern im Betreiben. Sobald echte Nutzer, mehrere Rollen und personenbezogene Daten ins Spiel kommen, braucht eine Lovable-App dieselbe Sorgfalt wie jede andere Software: geprüfte Datenbankregeln, keine Secrets im Frontend, Backups, Staging und jemanden, der den Code verantwortet.

Die gute Nachricht aus unseren Projekten: Dieser Schritt ist fast immer kleiner als ein Neubau. Wie Vibe Coding im Unternehmen insgesamt sinnvoll eingesetzt wird, lesen Sie in unserem Beitrag Was ist Vibe Coding?.

Häufige Fragen

Ist eine Lovable-App sicher genug für Kundendaten?

Sie kann es sein, aber nicht automatisch. Lovable erzeugt funktionierende Apps, prüft aber nicht, ob die Datenbankregeln fachlich richtig sind. Bevor Kundendaten in die App fließen, sollten Row Level Security auf allen Tabellen, Rollentests mit echten Anmeldungen und ein Secret-Scan erledigt sein.

Reicht der eingebaute Lovable-Sicherheitsscan aus?

Als Grundschutz ja, als Freigabe für sensible Daten nein. Der Scan erkennt fehlende Regeln und bekannte Probleme in Abhängigkeiten. Ob eine vorhandene Regel zu weit gefasst ist und Nutzer fremde Daten sehen, findet nur ein Test mit echten Rollen und bewussten Umgehungsversuchen.

Kann ich den Code meiner Lovable-App exportieren?

Ja. Über die GitHub-Synchronisation liegt der komplette Code in Ihrem eigenen Repository. Es ist gängiges React mit TypeScript und Supabase, das jedes moderne Entwicklungsteam übernehmen kann. Bei Lovable Cloud ist der Umzug der Daten in ein eigenes Supabase-Projekt etwas aufwendiger als beim Code.

Sollte ich Lovable Cloud oder ein eigenes Supabase-Projekt nutzen?

Für Prototypen ist Lovable Cloud bequem und ausreichend. Für eine App, die produktiv geht und personenbezogene Daten verarbeitet, empfehlen wir ein eigenes Supabase-Projekt in einer EU-Region. Sie behalten direkten Zugriff auf Datenbank, Backups und Logs und sparen sich später den Umzug.

Muss eine Lovable-App für den Produktivbetrieb neu programmiert werden?

Fast nie. In unseren Audits ließen sich die gefundenen Lücken gezielt schließen. Bei einem Projekt dauerte das Nachhärten nach unserer Schätzung Tage, ein Neubau hätte zwei bis vier Monate gekostet. Der Prototyp behält seinen Wert und bekommt das Fundament, das ihm fehlt.

Was kostet ein Security-Check für eine Lovable-App?

Das hängt von der Zahl der Rollen, Mandanten und Schnittstellen ab. Eine interne App mit zwei Rollen ist schneller geprüft als eine Plattform mit Zahlungen und Dokumenten. Im kostenlosen Erstgespräch schauen wir auf den Stand Ihrer App und sagen, was vor dem Go-live zwingend ist.

Sie haben eine Lovable-App gebaut und wollen wissen, ob sie bereit für echte Nutzer ist? Dann lassen Sie uns gemeinsam draufschauen. Buchen Sie ein unverbindliches Erstgespräch, und wir sagen Ihnen ehrlich, was vor dem Go-live fehlt und was warten kann.