Case Study: Von Lovable-Prototyp zu sicherer SaaS in 2 Wochen

Dieser Artikel beschreibt ein reales Projekt. Details wurden anonymisiert, um die Vertraulichkeit des Kunden zu wahren. Die technischen Fakten sind unverändert.

Ausgangslage: Eine funktionierende App mit unsichtbaren Problemen

Marco (Name geändert) ist Unternehmensberater. Keine technische Ausbildung, aber eine klare Idee: ein Tool, mit dem seine Klienten Projekte planen, Fortschritte tracken und Berichte generieren können. Statt monatelang auf eine Agentur zu warten, baute er die App selbst — mit Lovable.

In drei Wochen hatte er eine funktionierende Anwendung:

React/TypeScript Frontend mit 12 Seiten
Supabase Backend mit 9 Datenbank-Tabellen
Nutzer-Registrierung und Login
Stripe-Integration für monatliche Abonnements
PDF-Export für Berichte
Dashboard mit Echtzeit-Daten

Die App sah professionell aus. Sie funktionierte. Marco zeigte sie drei Beta-Testern, die begeistert waren.

Dann wollte er live gehen. Und stellte sich die richtige Frage: Ist diese App bereit für echte Nutzer, die mir ihre Daten und ihre Kreditkartendaten anvertrauen?

Der Audit: Was wir gefunden haben

Marco schickte mir den Link zu seinem GitHub-Repository. Ich habe den Code systematisch durchgearbeitet — Datei für Datei, Endpunkt für Endpunkt. Das Ergebnis war typisch für Lovable-Apps dieser Größe.

Kritische Sicherheitsprobleme

4 von 9 Supabase-Tabellen ohne Row Level Security. Darunter die Tabelle mit Nutzer-Profildaten und die Tabelle mit Projektinformationen. Jeder mit der Supabase-URL konnte alle Daten aller Nutzer lesen. Namen, E-Mails, Projektdetails — alles offen.

Stripe Secret Key im Quellcode. Nicht der publishable Key — der Secret Key. Der Key, mit dem man Zahlungen auslösen, Abonnements ändern und Kundendaten einsehen kann. Er stand in einer Datei, die auf GitHub öffentlich zugänglich war.

Keine Autorisierungsprüfung auf API-Ebene. Ein eingeloggter Nutzer konnte durch einfaches Ändern einer ID in der URL auf die Projekte jedes anderen Nutzers zugreifen. Login ja, Zugriffsschutz nein.

Kein CSRF-Schutz, keine Security-Headers. Standard bei AI-generiertem Code, aber trotzdem ein Risiko, das geschlossen werden muss.

Strukturelle Probleme

2.800 Zeilen toten Code. Alte Versionen von Komponenten, auskommentierte Funktionen, ungenutzte Imports. Fast ein Drittel des gesamten Codes war überflüssig.

Keine Fehlerbehandlung. Wenn die Supabase-Verbindung abbrach, sah der Nutzer einen weißen Bildschirm. Wenn ein Stripe-Call fehlschlug, passierte nichts — keine Meldung, kein Fallback. Der Nutzer wusste nicht, ob seine Zahlung durchging.

Duplizierte Logik. Die Funktion zum Laden von Projektdaten existierte in vier leicht unterschiedlichen Versionen in vier verschiedenen Dateien. Ein Bug-Fix in einer Version betraf die anderen drei nicht.

DSGVO-Probleme

Daten in den USA gespeichert. Supabase Free-Plan, Standard-Region. Kein AVV, kein Hinweis in der Datenschutzerklärung.

Keine Datenschutzerklärung. Marco hatte schlicht vergessen, eine zu erstellen. Verständlich — Lovable generiert keine rechtlichen Dokumente.

Kein Löschkonzept. Nutzer konnten sich registrieren, aber es gab keinen Weg, die eigenen Daten einzusehen oder löschen zu lassen.

Die Entscheidung: Cleanup oder Neubau?

Die zentrale Frage bei jedem Projekt: Lohnt sich ein Cleanup oder wäre ein Neubau sinnvoller?

Bei Marcos App war die Antwort klar: Cleanup. Aus drei Gründen.

Die Kernlogik stimmte. Die Business-Logik — Projekte erstellen, Fortschritte tracken, Berichte generieren — war korrekt implementiert. Lovable hatte die Anforderungen gut verstanden.

Das Feature-Set war stabil. Marco wusste genau, was die App tun soll. Keine größeren Änderungen geplant. Der Scope war klar.

Der Zeitdruck war real. Drei Klienten warteten auf das Tool. Ein Neubau hätte sechs bis acht Wochen gedauert. Ein Cleanup zwei.

Was wir in 2 Wochen gemacht haben

Woche 1: Security und Stabilität

Tag 1–2: Security-Fixes

Alle 9 Supabase-Tabellen mit korrekten RLS-Policies versehen
Stripe Secret Key aus dem Code entfernt, in Umgebungsvariablen verschoben
GitHub-Repository auf privat gestellt
Stripe-Key rotiert (der alte war kompromittiert)
Autorisierungsprüfungen auf allen API-Endpunkten implementiert
Security-Headers und CSRF-Schutz aktiviert

Tag 3–4: Refactoring

2.800 Zeilen toten Code entfernt
Duplizierte Projektlade-Funktion in eine einzige, zentrale Funktion zusammengeführt
Datenbankzugriffe in eigene Service-Module ausgelagert
Komponenten-Struktur bereinigt

Tag 5: Error-Handling

Globale Fehlerbehandlung implementiert
Spezifische Fehlermeldungen für Stripe-Probleme
Fallbacks für Datenbankverbindungs-Abbrüche
Ladezeiten-Indikatoren für alle asynchronen Aktionen

Woche 2: Deployment und Compliance

Tag 6–7: Hosting-Setup

App auf Vercel deployt
Eigene Domain mit SSL konfiguriert
CI/CD-Pipeline: Jeder Push auf main deployt automatisch
Environment Variables sicher in Vercel hinterlegt
Sentry Error-Tracking eingerichtet

Tag 8–9: DSGVO-Grundlagen

Supabase auf EU-Region migriert
Technisches Löschkonzept implementiert (Nutzer kann Account und alle Daten löschen)
Cookie-Banner mit Einwilligungsmanagement integriert
Datenschutzerklärung-Seite vorbereitet (Inhalt vom Anwalt)
Impressum-Seite eingebaut

Tag 10: Abnahme und Dokumentation

Vollständiger Re-Audit aller Security-Fixes
Übergabe-Dokumentation erstellt
Walkthrough-Call mit Marco

Das Ergebnis in Zahlen

Metrik	Vorher	Nachher
Supabase-Tabellen ohne RLS	4 von 9	0 von 9
Secrets im Quellcode	3 (Stripe, Supabase, SendGrid)	0
Toter Code	2.800 Zeilen	0
Security-Headers	0	5 (CSP, X-Frame, HSTS, X-Content-Type, Referrer)
Error-Handling	Keines	15 spezifische Fehlerszenarien abgedeckt
Hosting	lovable.app-Subdomain	Eigene Domain, SSL, Vercel
Monitoring	Keines	Sentry + Uptime-Check
DSGVO-Konformität	Nicht gegeben	Technische Grundlagen umgesetzt

Was Marco sagt

"Ich wusste, dass meine App irgendwie 'nicht fertig' war, aber ich konnte nicht benennen, was fehlte. Der Audit hat mir das schonungslos, aber verständlich gezeigt. Und nach dem Cleanup konnte ich meinen Klienten die App mit gutem Gewissen präsentieren."

Lessons Learned

Lovable ist ein hervorragendes Prototyping-Tool

Ohne Lovable hätte Marco diese App nicht gebaut. Die Alternative wäre gewesen: Monate auf eine Agentur warten und deutlich mehr investieren. Lovable hat ihm ermöglicht, seine Idee schnell zu validieren. Das ist ein enormer Wert.

Der Prototyp ist nicht das Produkt

Was Lovable liefert, ist ein funktionierender Prototyp. Nicht mehr, nicht weniger. Die Lücke zwischen Prototyp und Produkt ist real — aber sie ist überbrückbar. Und sie ist kleiner, als die meisten denken.

Zwei Wochen, nicht zwei Monate

Der häufigste Irrtum: "Wenn der Code nicht perfekt ist, muss man alles neu bauen." In den meisten Fällen stimmt das nicht. Ein gezielter Cleanup ist schneller, günstiger und erhält die Arbeit, die du schon investiert hast.

Security ist kein Feature — es ist die Grundlage

Marcos App hatte jedes Feature, das seine Klienten brauchten. Was fehlte, war unsichtbar: Sicherheit, Datenschutz, Stabilität. Die Dinge, die du nicht siehst, wenn du die App benutzt — aber die du sofort merkst, wenn sie fehlen.

Steht deine App vor demselben Schritt?

Wenn du mit Lovable, Bolt, Cursor oder einem ähnlichen Tool eine App gebaut hast und live gehen willst, stehst du vermutlich an einem ähnlichen Punkt wie Marco.

Die App funktioniert. Du bist stolz darauf. Aber du bist dir nicht sicher, ob sie bereit ist.

Lass uns das herausfinden. Schick mir den Link zu deiner App oder deinem GitHub-Repo. In 30 Minuten sage ich dir ehrlich, wo du stehst — und was nötig ist.

Erstgespräch vereinbaren