Lovable-App produktionsreif machen: Das vor dem Launch prüfen

Mit Lovable lässt sich eine App einfach beschreiben und beim Entstehen beobachten: Screens, Registrierung, eine Datenbank, sogar Zahlungen. Für Gründerinnen und Gründer ist diese Geschwindigkeit wirklich wertvoll. Der Haken: Ein Prototyp und ein Produkt sind zwei verschiedene Dinge. Ein Prototyp hat einen einzigen Nutzer, freundliche Testdaten und keine Konsequenzen. Ein Produkt hat fremde Nutzer, personenbezogene Daten und einen Ruf zu verlieren.

Dieser Leitfaden richtet sich an Gründer, die eine Lovable-App produktionsreif machen wollen, ohne zu raten. Wenn Sie zunächst eine schnelle Einschätzung Ihres Stands wünschen, nutzen Sie unseren kostenlosen AI App Health Check. Er zeigt, in welchen der folgenden Bereiche der größte Handlungsbedarf besteht. Lovable und Supabase entwickeln sich schnell weiter. Prüfen Sie daher jedes plattformspezifische Detail anhand Ihrer eigenen Projekteinstellungen und der aktuellen Dokumentation.

Prototyp oder Produktion: Was sich tatsächlich ändert

Lovable ist ein KI-App-Builder, der häufig mit Supabase für Authentifizierung, eine Postgres-Datenbank und Dateispeicher kombiniert wird. Diese Kombination verlagert viel Sicherheitsverantwortung in die Konfiguration: Datenbankrichtlinien, Weiterleitungseinstellungen, API-Schlüssel und Speicherregeln. Der Builder erzeugt den Code, aber er kennt weder Ihre echten Nutzer noch Ihr echtes Geld noch Ihre echten Fehler.

Produktionsreife bedeutet, dass jede dieser Konfigurationen von jemandem getestet wurde, der versucht hat, sie zu knacken. Die folgenden Abschnitte folgen der Reihenfolge, in der Probleme erfahrungsgemäß am meisten schaden.

Wo mit Lovable erstellte Apps typischerweise technische Aufmerksamkeit brauchen

1. Supabase Row-Level Security

Das ist der erste Punkt, den Sie prüfen sollten. In einem Supabase-Setup spricht der Browser über einen öffentlichen Schlüssel mit der Datenbank, und Row-Level-Security-Richtlinien (RLS) entscheiden, was jeder Nutzer lesen oder schreiben darf. Eine Tabelle ohne Richtlinien oder mit Richtlinien, die alles erlauben, kann die Daten sämtlicher Kunden offenlegen.

Testen Sie dies mit zwei Konten. Legen Sie Kunde A und Kunde B mit getrennten Datensätzen an. Melden Sie sich als B an und versuchen Sie dann, die Datensätze von A zu öffnen, zu bearbeiten und zu löschen, indem Sie IDs in URLs ändern und die API direkt aufrufen. Funktioniert davon irgendetwas, haben Sie einen Launch-Blocker. Unser Leitfaden zu den sieben RLS-Fehlern in KI-gebauten Apps erklärt die Muster, auf die Sie achten sollten, darunter Rollen, die dort gespeichert sind, wo Nutzer sie ändern können, und zu offene Storage-Buckets.

2. Authentifizierung, Weiterleitungs-URLs und E-Mail-Abläufe

Eine Authentifizierung, die auf einer Vorschau-URL funktioniert, bricht auf Ihrer echten Domain oft – oder verhält sich schlimmer noch zu locker. Prüfen Sie:

• Die Site-URL und die erlaubten Weiterleitungs-URLs enthalten Ihre Produktionsdomain und keine veralteten Vorschau-Adressen oder Platzhalter, die Sie nicht mehr benötigen.
• E-Mail-Bestätigung, Magic Links und Passwort-Zurücksetzen funktionieren in der Produktion von Anfang bis Ende, und Rücksetz-Links laufen ab und lassen sich nicht erneut verwenden.
• Authentifizierungs-E-Mails werden von Ihrer eigenen Domain mit konfigurierten SPF, DKIM und DMARC versendet, damit sie nicht im Spam landen. Der standardmäßige E-Mail-Versender ist in der Regel für Tests gedacht und nicht für echten Datenverkehr; prüfen Sie Ihre Projekteinstellungen.
• Aktionen nur für Administratoren werden auf dem Server oder per Datenbankrichtlinie durchgesetzt und nicht bloß in der Oberfläche ausgeblendet.

3. Geheimnisse und was im Browser landet

Alles, was ins Frontend gebündelt wird, ist öffentlich. Ein öffentlicher Supabase-Schlüssel (anon) ist dafür ausgelegt, sichtbar zu sein, aber er ist nur sicher, wenn Ihre RLS-Richtlinien korrekt sind. Ein Service-Role-Schlüssel, ein geheimer Zahlungsschlüssel oder ein Schlüssel eines KI-Anbieters im Frontend-Code ist ein gravierendes Leck. Durchsuchen Sie Ihr gebautes JavaScript und Ihren Repository-Verlauf nach Schlüsseln, rotieren Sie alles, was jemals offengelegt wurde, und verlagern Sie Aufrufe, die Geheimnisse benötigen, in serverseitige Funktionen. Setzen Sie für jeden KI- oder Drittanbieter-API-Schlüssel Ausgabenlimits.

4. Stripe-Webhooks und Zugriffsrechte

Ein Zahlungsablauf, der im Testmodus funktioniert, ist noch nicht fertig. Kostenpflichtiger Zugriff sollte aus verifizierten Webhook-Ereignissen stammen und nicht von der Erfolgsseite, auf der der Browser landet. Stellen Sie sicher, dass Signaturen geprüft werden, wiederholte Zustellungen sicher behandelt werden und fehlgeschlagene Verlängerungen, Kündigungen und Rückerstattungen den Zugriff korrekt ändern. Test- und Live-Schlüssel dürfen sich nie vermischen. Die Details finden Sie in unserem Leitfaden zu Stripe-Webhooks und Abonnements in KI-gebauten Apps.

5. Struktur des generierten Codes, Duplikate und Tests

Generierter Code funktioniert häufig, wiederholt sich aber: ähnliche Komponenten werden mit kleinen Abweichungen kopiert, Geschäftsregeln sind über die Oberfläche verstreut, und es gibt keine automatisierten Tests. Das ist am ersten Tag kein Notfall, erklärt aber, warum eine kleine Änderung etwas völlig Unabhängiges kaputt machen kann. Bevor Sie skalieren, ergänzen Sie Tests rund um die Zahlungs- und Berechtigungspfade, bündeln Sie duplizierte Regeln an einer Stelle und halten Sie Datenbankänderungen in versionierten Migrationen fest, damit sich das Schema neu erstellen und prüfen lässt.

6. Performance und Fehlerüberwachung

Eine Demo mit zehn Zeilen ist schnell. Echte Daten decken Abfragen auf, die alles laden, fehlende Datenbankindizes und Seiten, die zu viel laden. Richten Sie Fehlerüberwachung und Verfügbarkeitsalarme ein, die eine Person erreichen, damit Sie von einem Ausfall erfahren, bevor es ein Kunde Ihnen sagt. Prüfen Sie Listenseiten mit realistischen Datenmengen statt mit Beispielzeilen.

7. Deployment, Domains und Backups

Legen Sie fest, wo die App läuft, wer deployen darf und wie Sie zur letzten funktionierenden Version zurückkehren. Halten Sie Staging und Produktion getrennt, jeweils mit eigener Datenbank und eigenen Schlüsseln. Bestätigen Sie Ihre Domain- und HTTPS-Konfiguration, aktivieren Sie Datenbank-Backups und spielen Sie tatsächlich eines zurück, um zu sehen, wie lange es dauert. Ein Backup, das Sie nie wiederhergestellt haben, ist eine Hoffnung und kein Plan.

8. Eigentum am Code, Repository und Export

Stellen Sie sicher, dass Sie besitzen, was Sie aufbauen. Verbinden Sie das Projekt mit einem Repository in einem Konto, das Sie kontrollieren, vergewissern Sie sich, dass Sie die App außerhalb des Builders ausführen können, und betreiben Sie das Supabase-Projekt, den Domain-Registrar und das Zahlungskonto unter Unternehmens-Logins statt unter dem persönlichen Zugang einer Einzelperson oder eines Auftragnehmers. Funktionen und Bedingungen von Lovable ändern sich, prüfen Sie daher die aktuelle Dokumentation. Liegt der Code in Ihrem eigenen Repository, wird auch jede spätere Entwicklungsarbeit deutlich leichter.

Was Sie bedenkenlos weiter per Prompt erledigen können und wann ein Entwickler nötig ist

Weiter prompten können Sie bei Arbeiten, bei denen ein Fehler sichtbar und günstig ist: Layout, Texte, Farben, neue Screens, die einem Nutzer nur seine eigenen Daten zeigen, und kleine Inhaltsfunktionen. Prüfen Sie das Ergebnis, behalten Sie eine Version, zu der Sie zurückkehren können, und lassen Sie das Tool nichts neu schreiben, was bereits funktioniert.

Einen Entwickler hinzuziehen sollten Sie, wenn ein Fehler unsichtbar oder teuer wäre: Datenbankrichtlinien, Authentifizierungseinstellungen, alles rund um Zahlungen, Migrationen, die Daten ändern oder löschen, Geheimnisse und jeder Bereich, in dem jede Korrektur etwas anderes zu zerstören scheint. Wenn Sie nicht erklären können, wer in Ihrer App was sehen darf, ist das allein Grund genug. Diese Entscheidung behandeln wir ausführlicher in wann Sie mit dem Prompten aufhören und einen Entwickler hinzuziehen sollten, die vollständige Liste der Prüfpunkte finden Sie in der Checkliste mit 20 Punkten zur Produktionsreife.

Ein Rettungsweg Schritt für Schritt

1. Audit. Lassen Sie Zugriffskontrolle, Datenrichtlinien, Zahlungen, Geheimnisse und Deployment unabhängig prüfen. Das Ergebnis sollte eine priorisierte Liste mit Schritten zur Reproduktion jedes Problems sein, kein vager Score.
2. Kritische Probleme beheben. Schließen Sie zuerst alles, was Daten oder Geld preisgibt: fehlende oder zu freizügige Richtlinien, geleakte Schlüssel, nicht verifizierte Webhooks.
3. Härten. Ergänzen Sie Tests für Berechtigungs- und Abrechnungspfade, verlagern Sie Geheimnisse und sensible Logik auf den Server und richten Sie Migrationen, Staging, Monitoring und Backups ein.
4. Launch. Veröffentlichen Sie mit einem Rollback-Plan, einem benannten Verantwortlichen und Alarmen, auf die jemand reagiert. Beginnen Sie nach Möglichkeit mit einer kleinen Gruppe echter Nutzer.
5. Wartung. Abhängigkeiten, Plattformänderungen und neue Funktionen kommen laufend hinzu. Legen Sie fest, wer Updates einspielt und Fehler beobachtet, ob Ihr eigenes Team oder ein Wartungsplan.

Beachten Sie, was fehlt: ein Neuaufbau. Die meisten Apps lassen sich an Ort und Stelle reparieren, und ein Audit zeigt Ihnen, ob Ihre dazugehört.

So unterstützt UnlockLive

UnlockLive IT arbeitet von Toronto aus mit einem Engineering-Zentrum in Dhaka, und genau diese Phase begleiten wir.

• Das AI App Technical Audit ist der erste Schritt: Wir prüfen Ihr Lovable- und Supabase-Setup, testen die riskanten Bereiche und übergeben Ihnen eine priorisierte Korrekturliste, die Sie mit uns oder ohne uns umsetzen können.
• Der Service AI App Repair and Launch führt diese Liste zu Ende: kritische Probleme beheben, die App härten und auf einer Infrastruktur live bringen, die Sie kontrollieren.

Wenn Sie unsicher sind, ob Sie eines von beiden brauchen: Ein technisches Audit unterscheidet sich auch von einem Penetrationstest; unser Vergleich von Audits, Penetrationstests und Code-Reviews erklärt, was zu Ihrer Situation passt.

Starten Sie mit einem kostenlosen Check

Bevor Sie Geld ausgeben, finden Sie heraus, wo Sie stehen. Unser kostenloser AI App Health Check dauert wenige Minuten und zeigt die Bereiche Ihrer Lovable-App, die einen genaueren Blick am meisten verdienen. Testen Sie anschließend die Unbekannten anhand der obigen Liste selbst und ziehen Sie für die Teile, die Sie nicht prüfen können, einen Entwickler hinzu. Eine Lovable-App produktionsreif zu machen heißt vor allem, Probleme zu finden, solange nur Sie selbst davon betroffen sind.