Zum Inhalt springen

Lovable in Produktion: Code-Export und App-Sicherheit

Für Gründer · Aktualisiert

Filip PapranecGründer von Digitaliko

Lovable in Produktion: Export, Sicherheit, Betrieb. Illustration: links ein Prototyp, in der Mitte GitHub, rechts eine App mit Prüfungen.Lovable in Produktion: Export, Sicherheit, Betrieb. Illustration: links ein Prototyp, in der Mitte GitHub, rechts eine App mit Prüfungen.

Von Lovable in Produktion kommen Sie, ohne neu zu schreiben, was funktioniert. Sie haben Ihre App in Lovable zusammengeklickt, die ersten Leute testen sie, und Sie wissen nicht, ob sie den echten Betrieb aushält. Code aus Lovable lässt sich über GitHub exportieren und läuft auch außerhalb von Lovable. Meist fehlen Zugriffskontrolle für Daten, Backups, Tests und Betrieb. Das alles lässt sich ergänzen.

Vibe Coding baut Ihnen einen Prototyp. Wir bauen Software, auf der ein Unternehmen läuft. Unten: wie Sie den Code herausbekommen, was Sie zuerst prüfen und wann Sie Lovable verlassen. Was Vibe Coding allgemein ist, erklären wir in Vibe Coding: was es ist und warum Software billig wurde.

Eine Lovable-App in Produktion am Beispiel von Buchungen für einen Friseursalon: im Prototyp eine Tabelle ohne Regeln, ein geheimer Schlüssel im Code und keine Backups, im Echtbetrieb sieht jeder nur seine Zeilen, Schlüssel liegen außerhalb des Codes, Rollen werden auf dem Server geprüft und Backups wurden einmal wiederhergestellt.Eine Lovable-App in Produktion am Beispiel von Buchungen für einen Friseursalon: im Prototyp eine Tabelle ohne Regeln, ein geheimer Schlüssel im Code und keine Backups, im Echtbetrieb sieht jeder nur seine Zeilen, Schlüssel liegen außerhalb des Codes, Rollen werden auf dem Server geprüft und Backups wurden einmal wiederhergestellt.

Lässt sich Code aus Lovable exportieren?

Ja. Lovable kann ein Projekt mit GitHub verbinden. Der Code liegt dann in Ihrem Repository, und Sie können ihn überall deployen. Datenbank und Anmeldung laufen meist in Supabase oder Lovable Cloud.

Den ersten Punkt haben wir selbst einmal falsch gemacht. Unser Prototyp für einen Interessenten lief auf einem privaten Konto, und der Link wäre mit der Person gegangen. Bevor Sie etwas ändern, haken Sie ab, was Sie schon haben:

Deployment außerhalb von Lovable ist nicht Schritt eins. Erst Sicherheit, dann der Umzug, falls überhaupt.

Ist eine Lovable-App sicher?

Ohne Prüfung lässt sich das nicht sagen. Die häufigste Lücke steckt nicht in den Screens, sondern in der Datenbank. Der Browser jedes Besuchers bekommt einen öffentlichen Schlüssel zur Datenbank. Danach schützen nur die Zugriffsregeln die Daten. In Supabase heißen sie Row Level Security.

Fehlen die Regeln oder lassen sie jeden herein, sieht ein Kunde die Daten eines anderen. Die App sieht trotzdem gut aus. Der Fehler zeigt sich erst, wenn jemand danach sucht.

Das haben wir beim Audit einer Lovable-App geprüft:

Was prüfenWie es schlecht aussiehtWas tun
Zugriffsregeln der DatenbankTabelle ohne Regeln oder mit Regel „alle“Jeder sieht nur seine Zeilen, Sensibles läuft über den Server
Schlüssel und PasswörterGeheimer Schlüssel direkt im CodeAußerhalb des Repositorys und ausgetauscht, falls er je dort war
Anmeldung und RollenAdmin erkennt man nur am versteckten ButtonRolle auf dem Server geprüft, nicht im Browser
ZahlungenDer Browser markiert eine Bestellung als bezahltNur der Zahlungsanbieter bestätigt den Status
BackupsKeine, oder nie wiederhergestelltRegelmäßig und mindestens einmal getestet
BetriebEin Kunde meldet den AusfallDie Warnung kommt vor der Beschwerde

Die allgemeine Liste für Prototypen aus jedem KI-Werkzeug finden Sie in Vom Vibe-Coding-Prototyp in die Produktion. Alle Prüfungen an einem Ort: 25 Punkte vor dem Start herunterladen (PDF).

Wie machen wir das?

Heute schreibt bei uns KI den gesamten Code. Filip steht für die Produktion ein. Der Unterschied liegt also nicht im Werkzeug. Er liegt darin, wer liest, was die KI geschrieben hat, und wer dafür einsteht, wenn es bei Kunden läuft.

Eine Lovable-App haben wir bereits auditiert. Für einen Kunden haben wir außerdem Lovable-Prototypen in eine produktive App überführt.

Kleine Fehler entstanden, weil die Datenschicht unter dem Prototyp völlig anders war. Je mehr Kontext, desto besser das Ergebnis: der Prototyp, eine Beschreibung der Funktion und die Datenstruktur. Prototypen Sie deshalb so nah an der echten App wie möglich.

Filip Papranec
Filip Papranec
Gründer von Digitaliko

Bei einer Lovable-App beginnen wir deshalb nicht mit Neuschreiben. Wir gehen in dieser Reihenfolge vor:

  1. Prüfung

    Nach der Tabelle oben, zuerst der Datenzugriff.

  2. Sicherheitskorrekturen

    Datenregeln, Schlüssel raus aus dem Code, Rollen auf dem Server.

  3. Wiederholbares Deployment

    Jede Änderung nimmt denselben Weg, nicht von Hand.

  4. 30 Tage beim Übergang in den Betrieb

    Wir bleiben dabei, bis alles läuft.

Genau darum geht es in unserer MVP-Entwicklung für Gründer. Hat jemand anderes die App gebaut und Sie wollen sie ganz übernehmen, lesen Sie App von anderem Anbieter übernehmen.

In Lovable bleiben oder gehen?

Am Anfang beides. Lovable und GitHub synchronisieren sich, Sie können also weiter Screens ausprobieren, während wir den Rest festigen. Ihre Änderungen laufen durch dieselbe Prüfung wie unsere.

Ganz zu gehen lohnt sich, wenn das Produkt wächst und es mehr Änderungen als Experimente gibt. Dann wird meist nur noch im Repository gearbeitet. Lovable bleibt ein Werkzeug für schnelle Skizzen.

Wann wir davon abraten

  • Nur Sie und ein paar Kollegen nutzen die App. Sie muss nicht in den Betrieb. Prüfen Sie die Datenregeln und sichern Sie.
  • Sie validieren noch die Idee und haben keine Nutzer. Machen Sie in Lovable selbst weiter. Einen Anbieter brauchen Sie, wenn jemand das Produkt will.
  • Sie wollen neue Funktionen nur klicken und nichts prüfen. Dabei helfen wir nicht. Code-Review ist der Grund, uns zu holen.
  • Sie suchen jemanden, der es gegen Firmenanteile fertig baut. Das machen wir nicht. Suchen Sie einen technischen Mitgründer.

Was vor dem ersten Gespräch vorbereiten?

Drei Dinge reichen:

  1. Zugang zum Lovable-Projekt oder zum GitHub-Repository,
  2. wer die App heute nutzt und wofür,
  3. was schon kaputtgegangen ist oder wovor Sie Angst haben.

Wir melden uns innerhalb von zwei Arbeitstagen und wählen gemeinsam, was wir zuerst lösen.

Wenn Sie lieber zuerst sprechen möchten, buchen Sie ein 15-Minuten-Meeting mit Filip.

Was würde passieren, wenn sich morgen jemand die Daten Ihrer Kunden ansieht?

Kurz gesagt

  • Code aus Lovable bekommen Sie über GitHub heraus. Repository, Datenbank und Schlüssel sollten der Firma gehören.
  • Die häufigste Lücke sind die Zugriffsregeln der Datenbank. Ohne sie sieht ein Kunde die Daten eines anderen.
  • Neuschreiben ist meist nicht nötig. Ergänzt werden Datenzugriff, Backups, Deployment und Monitoring.
  • Am Anfang können Sie in Lovable bleiben. Wenn die Änderungen zunehmen, zieht die Arbeit ins Repository.

Häufige Fragen

Wie lade ich den Code aus Lovable herunter?

Verbinden Sie das Lovable-Projekt mit GitHub, dann liegt der Code in Ihrem Repository. Von dort können Sie ihn auch außerhalb von Lovable deployen. Die Datenbank läuft meist in Supabase und wird separat exportiert.

Ist eine Lovable-App sicher?

Ohne Prüfung lässt sich das nicht sagen. Die häufigste Lücke sind die Zugriffsregeln der Datenbank. Der Browser bekommt einen öffentlichen Schlüssel, und nur diese Regeln schützen die Daten. Fehlen sie, sieht jeder die Daten.

Muss ich meine Lovable-App neu schreiben?

Meist nicht. Öfter reicht es, den Datenzugriff zu korrigieren, Schlüssel aus dem Code zu holen und Backups, Deployment und Monitoring einzurichten. Ob ein Neuschreiben nötig ist, zeigt erst ein Blick in den Code.

Kann ich Lovable nach der Übergabe weiter nutzen?

Ja, eine Zeit lang. Lovable und GitHub synchronisieren sich, sodass Ihre Änderungen und unsere Korrekturen in einem Repository zusammenkommen. Alles läuft durch dieselbe Prüfung wie der restliche Code.

Fragen Sie eine KI zu diesem Artikel

Die KI nutzt dabei auch unsere anderen Artikel und Erfahrung aus echten Projekten.

ChatGPTClaudePerplexity
Blog

Weitere Artikel

Für Gründer

Vibe Coding in Produktion: was dem Prototyp fehlt

Ein Vibe-Coding-Prototyp kommt in die Produktion, wenn Sie Sicherheit, Backups, wiederholbares Deployment, Tests und Monitoring ergänzen. Was fehlt, wie Sie es prüfen und wann ein Neuanfang lohnt.

Für Gründer

App von einem anderen Anbieter übernehmen

Eine App von einem anderen Anbieter übernehmen Sie in drei Schritten: Code, Zugänge und Daten sichern, jemanden in den Code schauen lassen und erst dann entscheiden. Checkliste und drei mögliche Urteile.

Für Gründer

PWA oder native App: was braucht Ihr Unternehmen?

Eine PWA reicht, wenn die Nutzer die App über einen Link bekommen, den Sie schicken. In den App Store und zu Google Play gehen Sie, wenn neue Leute Sie dort finden sollen oder Sie Funktionen brauchen, die das Web nicht hat. Vergleich, Selbsttest und Einstieg.

LinkedIn

Echte Erfahrungen, kein Hype

Filip Papranec, Gründer von Digitaliko. Auf LinkedIn lösen wir technische Herausforderungen, teilen Erfahrung aus der Entwicklung und zeigen, wie KI Unternehmen wirklich verändert. KI-Hype mögen wir nicht: Wir sind Realisten, keine Traumverkäufer.

Zeit, mit dem Planen aufzuhören und das Problem zu lösen.

Kontakt

  • Digitaliko s.r.o.
    Šípková 377/17
    958 03 Malé Uherce, Slowakei
  • Melden Sie sich bei uns
    info@digitaliko.com
    +421 950 595 506
    WhatsApp