Lovable — KI-Full-Stack-App-Generator
Übersicht
Lovable (lovable.dev) erzeugt und bearbeitet Web-Apps aus Chat-Prompts im Browser. Projekte verwenden Tailwind CSS und shadcn/ui; seit Mai 2026 erstellte Apps nutzen TanStack Start (servergerendert), ältere basieren auf React + Vite. Als Backend kannst du wählen: Lovable Cloud (integrierte Datenbank, Auth, Speicher, Echtzeit-Funktionen, basierend auf Supabase Open Source) oder dein eigenes Supabase-Projekt. Der Code kann bidirektional mit GitHub synchronisiert werden und die App wird auf einer Lovable-URL oder einer benutzerdefinierten Domain veröffentlicht. Es gibt nichts zu installieren und kein CLI; ein Agent hilft, indem er gute Prompts schreibt, die Ausgabe überprüft und am synchronisierten Repository arbeitet.
Anleitung
1. Vor dem ersten Prompt planen
Beantworte vier Fragen: Was ist es, wer nutzt es, warum, und was ist die Schlüsselaktion. Beschreibe die App abschnittsweise mit echten Texten, nicht mit Platzhaltern. Lovables Leitlinie: Ein Prompt über die gesamte Seite erzeugt Rauschen, ein abschnittsweiser Prompt erzeugt Signal. Gib eine Designrichtung vor („minimal“, „premium“, „verspielt“), um Typografie und Abstände zu steuern.
2. Backend wählen
- Neue Projekte: Lovable Cloud (Standard) oder Supabase, ausgewählt wenn das Backend erstmals aktiviert wird.
- Bestehende Supabase-verbundene Projekte funktionieren weiterhin. Es gibt keine Migration von Supabase zu Cloud und keinen One-Click-Umzug von Cloud zu einem eigenen Supabase-Projekt – entscheide daher frühzeitig.
3. Modi verwenden
Lovable hat einen Agent-Mode (baut und ändert Dinge) und einen Chat-Mode (diskutieren, planen, keine Änderungen). Der Plan-Mode kostet 1 Credit pro Nachricht; normale Änderungen kosten je nach Komplexität etwa 0,5–1,7 Credits. Füge „Stelle mir alle Fragen, die du vor dem Bauen brauchst“ hinzu, um klärende Fragen zu erhalten. Lege dauerhafte Regeln (Stack, Benennung, Ton) im Projekt- oder Workspace-Wissen fest, damit sie in Chats erhalten bleiben.
4. Sicherheit überprüfen
Generierte Tabellen sollten Row-Level-Security (RLS) haben. Lies jede Richtlinie, führe den integrierten Sicherheitsscan aus und teste mit zwei verschiedenen Benutzern, bevor du die App veröffentlichst.
5. Code synchronisieren und übernehmen
Verbinde GitHub über die Projekteinstellungen. Die Synchronisation ist bidirektional für jeweils einen Branch (Standard-Branch, sofern nicht umgeschaltet); neue Branches starten vom aktiven Branch aus. Du kannst Lovable-Projekte nur nach GitHub exportieren, nicht ein bestehendes Repository importieren, und Dateien über 10 MB können von Lovable nicht bearbeitet werden. Das Trennen behält beide Kopien, aber ein erneutes Verbinden erzeugt ein neues Repository.
6. Preise
Kostenlos, Pro, Business und Enterprise; die Preisgestaltung erfolgt nach Credits, nicht nach Sitzen. Kostenlos beinhaltet 5 tägliche Build-Credits (bis zu 30 pro Monat) plus kleine Cloud-Credits. Aktuelle Preise siehe lovable.dev/pricing.
Beispiele
Beispiel 1: Wartelisten-App mit Empfehlungen
Anfrage: „Verwende Lovable, um eine SaaS-Warteliste zu bauen: Anmeldeformular mit Zähler, Empfehlungslinks, eine Rangliste und eine Admin-Seite.“
Prompt zum Einfügen:
Baue eine Wartelisten-Website für „Parcelly“, ein Versandlabel-Tool für Etsy-Verkäufer.
Abschnitte: Hero („Drucke Labels in 10 Sekunden“) mit einem E-Mail-Formular und einem Live-Anmeldezähler; eine Rangliste der Top 10 Empfehler; /admin-Seite hinter E-Mail-Login, die Anmeldungen auflistet und CSV exportiert.
Jede Anmeldung erhält einen eindeutigen Empfehlungslink (?ref=code), der dem Empfehler gutgeschrieben wird.
Stil: minimal, Dark Mode. Verwende Lovable Cloud für Daten und Auth.
Stelle mir alle Fragen, die du vor dem Bauen brauchst.
Ergebnis: Lovable fragt nach Einladungs-E-Mails, erstellt dann Seiten, eine signups-Tabelle mit Richtlinien und eine Vorschau-URL. Eine vernünftige Tabelle und Richtlinien zum Abgleichen mit der generierten:
create table public.signups (
id uuid primary key default gen_random_uuid(),
email text not null unique,
referral_code text not null unique default encode(gen_random_bytes(6), 'hex'),
referred_by uuid references public.signups(id),
created_at timestamptz not null default now()
);
alter table public.signups enable row level security;
create policy "anyone can join" on public.signups for insert to anon with check (true);
-- Alle Zeilen lesen muss auf Admins beschränkt sein, z. B. über eine user_roles-Tabelle
Beispiel 2: Iterieren und mit GitHub synchronisieren
Anfrage: „Füge ein Anmeldungen-über-Zeit-Diagramm hinzu, und bring dann den Code in mein Repo, damit ich in Cursor weiterarbeiten kann.“
Chat-Prompt: „Füge /admin ein Liniendiagramm der Anmeldungen pro Tag hinzu, das die vorhandenen Daten nutzt; zeige einen leeren Zustand an, wenn es keine Anmeldungen gibt.“ Dann: Projekteinstellungen, GitHub, Verbinden, Konto auswählen und Repository erstellen. Danach:
git clone [email protected]:parcelly-dev/parcelly-waitlist.git
cd parcelly-waitlist && npm install && npm run dev
Pushes auf den synchronisierten Branch erscheinen in Lovable; behalte lokale Änderungen auf diesem Branch (oder wechsle den Branch in den Projekteinstellungen).
Richtlinien
- Füge jede Kernfunktion in den ersten Prompt ein, ändere dann jeweils eine Sache pro Folge-Prompt, damit der Versionsverlauf nützlich bleibt; setze Lesezeichen für funktionierende Versionen.
- Füge keine API-Keys in den Chat ein; verwende die Dialoge für Secrets/Integrationen. Serverseitige Schlüssel gehören in Backend-Funktionen, niemals in Client-Code.
- Vertraue niemals blind generiertem RLS: Ein
insert ... with check (true)-Policy ist für ein öffentliches Formular in Ordnung, eineselect-Policy jedoch nicht. - Credits werden durch Bauen, Hosting und KI-Funktionen verbraucht und sind nicht erstattungsfähig; bevorzuge für Fragen den Chat-/Plan-Mode.
- Nicht geeignet für native mobile Apps, stark angepasste Backends oder komplexe bestehende Monorepos: Verwende stattdessen einen Coding-Agenten im Repository.