Lovable-App funktioniert nicht in Produktion? So wird sie produktionsreif

Warum funktioniert meine Lovable-App in der Vorschau, aber nicht in Produktion?

In der Vorschau sind Sie ein einzelner Nutzer mit Testdaten, der die Wege anklickt, die Sie gebaut haben. Die Produktion bringt Fremde, echtes Geld und Zeit ins Spiel. Die Fehler, die dann folgen, sind selten eine schlechte Codezeile. Es sind fehlende Entscheidungen: wer welche Zeile lesen darf, was passiert, wenn eine Zahlung gelingt, aber der Browser geschlossen wird, und wer merkt, wenn keine E-Mails mehr verschickt werden.

• Datenlecks zwischen Nutzern. Supabase macht eine Tabelle in einem exponierten Schema für jede Rolle mit entsprechender Berechtigung les- und schreibbar, sofern Row-Level Security nicht aktiviert ist und ihre Richtlinien nicht stimmen.
• Geheimnisse im Browser. Der Publishable-(Anon-)Key darf ausgeliefert werden; der Service-Role-Key umgeht jede RLS-Richtlinie und darf niemals in den Browser gelangen.
• Zahlungen, die auseinanderlaufen. Ein Checkout, der auf eine Erfolgsseite zurückführt, ist kein Zahlungsnachweis. Der Server muss die Zahlung bei Stripe bestätigen.
• Änderungen, die alte Funktionen kaputt machen. Ohne Regressionstests kann jeder neue Prompt etwas zunichtemachen, das letzte Woche funktioniert hat.
• Stille Ausfälle. Ohne Überwachung finden Ihre Kunden den Fehler vor Ihnen.

Nichts davon ist typisch nur für Lovable. Jede schnelle erste Version, ob von einem Menschen oder einer KI geschrieben, hat meist dieselben Lücken, denn ein Prototyp soll die Idee beweisen, nicht Fremden standhalten.

Ist eine Lovable-App von Haus aus produktionsreif?

Teilweise. Laut Lovables eigener Dokumentation schreibt es Row-Level-Security-Richtlinien für Tabellen, wenn Sie Supabase verbinden, führt beim Veröffentlichen einen schnellen Sicherheitsscan aus (eine Datenbankprüfung, etwa auf Tabellen ohne RLS oder Regeln, die alle durchlassen, eine Prüfung der Abhängigkeiten und eine MCP-Server-Prüfung) und bietet einen tieferen Scan an, den Sie manuell starten. Dort steht auch klar, dass der Scan keine vollständige Sicherheit garantieren kann und eine gründliche Sicherheitsprüfung nicht ersetzt.

Das ist eine faire Beschreibung. Ein Scan kann Ihnen sagen, dass eine Richtlinie existiert. Er kann Ihnen nicht sagen, ob sie zu Ihren Geschäftsregeln passt – etwa dass ein Team-Admin Rechnungen sehen darf, ein Teammitglied aber nicht. Genau dieses Urteil ist, was produktionsreif in der Praxis bedeutet.

Was bedeutet produktionsreif für eine Lovable-App?

Wie binde ich Stripe-Zahlungen sicher in eine Lovable-App ein?

Lovables Stripe-Integration läuft über Edge Functions, sodass Ihr Secret Key nicht in der App landet, und Einmalzahlungen öffnen Stripe Checkout. Laut Lovables Dokumentation richtet sie standardmäßig keine Webhooks ein: Die App prüft den Zahlungs- und Abostatus direkt bei Stripe, und Webhooks können auf Anfrage ergänzt werden. Dort steht auch, dass sich Preis-IDs zwischen Test- und Live-Modus unterscheiden, sodass Sie für den Livegang neue brauchen.

Den Status bei Bedarf abzufragen, reicht für einen einfachen Checkout. Sobald Sie Abonnements verkaufen, wollen Sie meist auch Webhooks, denn Verlängerungen, abgelehnte Karten und Kündigungen passieren, wenn Ihr Nutzer nicht auf der Seite ist. Die Stripe-Dokumentation ist präzise darin, wie das sicher gelingt:

• Verifizieren Sie jeden Webhook mit dem Stripe-Signature-Header und Ihrem Endpoint-Secret, anhand des unveränderten Request-Bodys.
• Rechnen Sie mit Duplikaten und Ereignissen in falscher Reihenfolge. Speichern Sie die verarbeiteten Ereignis-IDs, damit jedes genau einmal behandelt wird (Idempotenz).
• Denken Sie daran, dass Stripe fehlgeschlagene Zustellungen im Live-Modus bis zu drei Tage lang wiederholt; ein defekter Endpoint kann bei seiner Wiederherstellung also Ereignisse mehrerer Tage nachspielen.
• Halten Sie Test- und Live-Secrets getrennt. Objekte des einen Modus sind im anderen nicht sichtbar.

Sollte ich es selbst reparieren, einen Freelancer beauftragen oder ein Team holen?

Wenn Ihre App eine Handvoll Nutzer, keine Zahlungen und keine sensiblen Daten hat, können Sie die Tabelle oben selbst durchgehen – mit Lovables Sicherheitsscan und dem Security Advisor von Supabase, der Tabellen ohne RLS und Richtlinien, die alle durchlassen, markiert. Das ist ein gut investierter Nachmittag.

Ein Freelancer oder ein Rettungssprint zum Festpreis passt zu einem bekannten, abgegrenzten Problem: eine defekte Integration, ein Audit. Dafür sind sie oft die günstigere Wahl. Was eine einmalige Korrektur Ihnen nicht gibt, sind die nächsten sechs Monate: Tests, Releases, Upgrades und der Vorfall außerhalb der Bürozeiten. Diese fortlaufende Verantwortung verkaufen wir: Plutonapps ist darauf spezialisiert, Lovable-Apps in die Produktion zu bringen und zu betreiben, und unser Vergleich von Agenturen, Freelancern, internen Einstellungen und Abos zeigt, wann welche Option passt.

Was passiert nach dem Start, und wer hat Rufbereitschaft?

Mit dem Start ändert sich die Arbeit, sie hört nicht auf. Jemand muss Fehler beobachten, Sicherheitsupdates einspielen, auf Vorfälle reagieren und die nächste Funktion ausliefern, ohne die letzte kaputtzumachen. Auf unserem Starter-Plan prompten Gründer weiter in Lovable, und unsere Entwickler bauen jede Version in das echte Produkt ein, führen bei jeder Änderung Regressions- und visuelle Regressionstests, Code-Review und Sicherheitsprüfungen durch, deployen zweimal pro Woche in die Produktion und bearbeiten bis zu fünf Notfälle in der Produktion pro Monat, mit Support zu Geschäftszeiten. Growth ergänzt Continuous Deployment und Support rund um die Uhr. Details und Preise stehen auf unserer Preisseite.