Lovable im Porträt: Web-Apps per Chat bauen, von der Idee bis zum Deployment

Lovable ist ein KI-App-Builder aus Stockholm, mit dem sich funktionsfähige Web-Anwendungen in natürlicher Sprache beschreiben statt von Hand programmieren lassen. Man tippt eine Beschreibung in ein Chatfeld, die KI erzeugt daraus React-Code, ein Interface und auf Wunsch ein Backend mit Datenbank. Das Ergebnis läuft sofort im Browser und lässt sich mit einem Klick veröffentlichen. Zielgruppe sind Gründer, Selbstständige und kleine Teams ohne tiefe Programmierkenntnisse, zunehmend aber auch Entwickler, die Prototypen abkürzen wollen.

Inhaltsverzeichnis

• Was macht Lovable und für wen lohnt es sich
• Vibe Coding: Software per Chat statt im Editor
• Funktionen im Überblick: Frontend, Backend, Deployment
• Mobile Apps und ihre Grenzen
• Lovable Preise und das Credits-Modell
• Datenschutz, Serverstandort und Auftragsverarbeitung
• Praxisbeispiel aus einer Vier-Personen-Agentur
• Grenzen, Kritikpunkte und Sicherheitsfragen
• Lovable vs. Bolt, v0 und Replit
• Häufige Fragen

Was macht Lovable? Der KI-App-Builder in Kurzform

Hinter Lovable steht die schwedische Lovable AB, hervorgegangen aus dem Open-Source-Projekt GPT Engineer. Das Produkt gehört zu der Werkzeugkategorie, die 2024 und 2025 rasant gewachsen ist: KI-Systeme, die nicht nur Codeschnipsel vorschlagen, sondern ganze Projekte anlegen, Dateien schreiben, Abhängigkeiten installieren und das Ergebnis direkt ausliefern. Das Unternehmen gehört nach eigenen Angaben zu den am schnellsten wachsenden Software-Firmen Europas und hat Mitte 2025 eine große Finanzierungsrunde abgeschlossen.

Technisch erzeugt Lovable ein Projekt auf Basis von React, TypeScript, Tailwind CSS und Vite. Das ist kein proprietäres Format, sondern ein gängiger Stack, den jeder Entwickler lesen kann. Der komplette Code lässt sich jederzeit mit einem GitHub-Repository synchronisieren. Genau das unterscheidet solche Tools von klassischen Baukästen: Es entsteht echter Code, keine Konfiguration in einer geschlossenen Plattform.

Typische Projekte, die Nutzer damit umsetzen: Landingpages und Marketing-Websites, interne Dashboards, Buchungssysteme, CRM-Light-Lösungen, Umfrage-Tools, Mitgliederbereiche mit Nutzer-Login, MVPs für eine neue Geschäftsidee. Der Sprung von der Skizze zum klickbaren Prototyp dauert oft nur wenige Min., der Weg zur produktionsreifen Anwendung deutlich länger.

Vibe Coding: Software per Chat statt im Editor

Der Begriff Vibe Coding stammt von Andrej Karpathy, der Anfang 2025 beschrieb, wie er Projekte baut, indem er der KI sagt, was er will, und den erzeugten Code kaum noch selbst liest. Man gibt die Richtung vor, die KI schreibt, man testet, meldet zurück, was nicht passt, und wiederholt das. Der Entwickler wird zum Auftraggeber und Reviewer.

Lovable hat dieses Prinzip zum Produkt gemacht. Der Dialog läuft komplett per Chat: "Baue eine Seite, auf der Kunden Termine buchen können, mit Kalenderansicht und Bestätigungsmail." Die KI legt Komponenten an, baut Routen, erzeugt Dummy-Daten und zeigt eine Live-Vorschau neben dem Chatfenster. Korrekturen funktionieren genauso. "Die Buttons sind zu groß, nutze unsere Markenfarbe #1A4D8F" reicht als Anweisung.

Vibe Coding hat eine klare Kehrseite. Wer nicht versteht, was im Hintergrund passiert, merkt auch nicht, wenn etwas schiefläuft: eine offene Datenbanktabelle, ein API-Schlüssel im Frontend, eine Preisberechnung, die auf dem Client stattfindet und sich manipulieren lässt. Je ernster das Projekt, desto mehr lohnt es sich, den Code wenigstens stichprobenartig zu lesen oder lesen zu lassen.

Was Lovable per Chat tatsächlich baut

Oberfläche, UI und Design

Die Stärke von Lovable liegt sichtbar im Frontend. Die erzeugten Oberflächen wirken aufgeräumt, nutzen shadcn/ui-Komponenten und sind von Haus aus responsiv. Wer ein Screenshot oder eine Figma-Datei hochlädt, bekommt eine erstaunlich nahe Umsetzung zurück. Für Feinarbeit gibt es einen visuellen Bearbeitungsmodus: Text, Abstände, Farben und Schriftgrößen lassen sich direkt anklicken und ändern, ohne dass dafür Credits verbraucht werden. Das spart spürbar Budget, weil kleine Design-Korrekturen sonst jede einzelne KI-Anfrage kosten würden.

Backend und Datenbank über Supabase

Ohne Backend bleibt jede App eine Attrappe. Lovable löst das über eine native Supabase-Integration. Man verbindet sein Supabase-Projekt, danach kann die KI Tabellen anlegen, Spalten ändern, Row-Level-Security-Regeln schreiben, Authentifizierung einrichten und Edge Functions deployen. Supabase basiert auf PostgreSQL, es ist also eine echte relationale Datenbank mit SQL-Zugriff, kein Pseudo-Speicher.

Damit sind Full-Stack-Anwendungen möglich: Registrierung und Nutzer-Login, Rollen und Rechte, Dateiuploads, serverseitige Logik, Webhooks. Für Zahlungen wird meist Stripe angebunden, für Mails Resend, für KI-Funktionen innerhalb der eigenen Anwendung ein API-Schlüssel von OpenAI oder Anthropic. Geheimnisse werden als Secrets in Supabase hinterlegt statt im Frontend-Code, was Lovable in den meisten Fällen korrekt vorschlägt. Überprüfen sollte man es trotzdem.

Versionierung, GitHub und Veröffentlichung

Jeder Chat-Schritt erzeugt eine Version, zu der man zurückspringen kann. Diese Funktion ist wichtiger, als sie klingt, denn die KI baut gelegentlich Dinge kaputt, die vorher funktioniert haben. Eine Zwei-Wege-Synchronisation mit GitHub erlaubt es, dass ein Entwickler im Team parallel in der IDE arbeitet und die Änderungen in Lovable wieder auftauchen. Veröffentlicht wird per Klick auf eine Subdomain, eine eigene Domain lässt sich in den bezahlten Tarifen verbinden.

Mobile Apps mit Lovable: was realistisch möglich ist

Hier wird es oft missverstanden. Lovable baut Web-Apps, keine nativen iOS- oder Android-Anwendungen. Was entsteht, läuft im Browser und ist für Smartphone-Bildschirme optimiert. Für viele Anwendungsfälle reicht das völlig: ein internes Tool, das Monteure unterwegs aufrufen, ein Kundenportal, ein Event-Check-in.

Wer echte mobile Apps im App Store braucht, hat zwei Wege. Erstens die Progressive Web App, die sich auf dem Homescreen ablegen lässt, aber keinen Store-Eintrag bekommt und bei Push-Benachrichtigungen und Hardwarezugriff eingeschränkt bleibt. Zweitens die Verpackung des erzeugten Projekts mit Capacitor, was über GitHub und eine lokale Entwicklungsumgebung läuft und damit genau die Programmierkenntnisse voraussetzt, die man eigentlich umgehen wollte. Mobile Apps sind also möglich, aber nicht der eigentliche Zweck dieses Tools.

Lovable Preise: Tarife, Credits und was sie bedeuten

Die Lovable Preise sind in US-Dollar ausgezeichnet und werden für Kunden aus Deutschland in Euro abgerechnet, zuzüglich Umsatzsteuer, sofern keine gültige USt-IdNr. hinterlegt ist. Die folgenden Werte sind gerundete Orientierungsgrößen, Stand Oktober 2025. Das Preismodell wurde seit dem Start mehrfach umgebaut, ein Blick auf die Preisseite vor dem Kauf ist Pflicht.

Im kostenlosen Tarif stehen pro Tag nur wenige Nachrichten zur Verfügung, gedeckelt durch ein Monatslimit. Das reicht, um das Prinzip zu testen und eine kleine Seite zu bauen. Für ernsthafte Projekte ist der Free-Plan nach ein, zwei Abenden aufgebraucht. Zusätzliche Credits lassen sich in den bezahlten Tarifen nachkaufen oder über höhere Stufen skalieren.

Wie Credits verbraucht werden

Ein Credit entsprach ursprünglich schlicht einer Nachricht an die KI. Mittlerweile ist der Verbrauch stärker an den tatsächlichen Aufwand gekoppelt: Eine komplexe Anweisung, bei der der Agent mehrere Dateien liest, Fehler sucht und Code umschreibt, kostet mehr als eine kleine Textänderung. Fragen im reinen Chat-Modus, in dem die KI nur antwortet, ohne Code zu schreiben, sind günstiger als Bau-Aufträge.

Daraus folgt eine praktische Regel: Credits gehen nicht beim Bauen verloren, sondern beim Debuggen. Wenn eine Anwendung in einer Fehlerschleife hängt und man fünfmal hintereinander "funktioniert immer noch nicht" schreibt, verbrennt das Budget ohne Ergebnis. Erfahrene Nutzer schreiben deshalb längere, präzisere Anweisungen, nutzen den Chat-Modus für Diagnose und springen bei hartnäckigen Problemen lieber auf eine funktionierende Version zurück, statt weiter zu reparieren.

Datenschutz und DSGVO: Sitz, Server und Auftragsverarbeitung

Für europäische Unternehmen ist der Firmensitz ein Argument. Lovable AB sitzt in Stockholm und unterliegt damit direkt der DSGVO. Ein Auftragsverarbeitungsvertrag wird angeboten und ist in den Geschäftskunden-Tarifen Standard. Wer personenbezogene Daten über eine mit Lovable gebaute Anwendung verarbeitet, braucht diesen Vertrag, und zwar bevor echte Kundendaten ins System fließen.

Entscheidend ist die Unterscheidung zwischen zwei Ebenen. Erstens die Plattform selbst: dort liegen der Projekt-Code, die Chatverläufe und Metadaten. Zweitens die Daten, die später in der fertigen Anwendung anfallen. Die liegen in der Regel nicht bei Lovable, sondern bei Supabase. Dort lässt sich beim Anlegen eines Projekts eine EU-Region wählen, etwa Frankfurt. Diese Wahl trifft man einmal, ändern lässt sie sich hinterher nur mit Migration. Bei Projekten mit Gesundheits-, Bewerber- oder Mandantendaten ist das der wichtigste Klick im ganzen Aufbau.

Dazu kommen Unterauftragsverarbeiter. Die Sprachmodelle stammen von Anbietern wie Anthropic, OpenAI und Google, das Hosting der veröffentlichten Seiten läuft über CDN-Dienstleister. Ein Teil dieser Verarbeitung findet in den USA statt. Für die Angemessenheit greift das EU-US Data Privacy Framework beziehungsweise Standardvertragsklauseln. Wer es sauber machen will, listet die Subunternehmer im eigenen Verarbeitungsverzeichnis und prüft die aktuelle Liste in der Dokumentation. Ein Opt-out aus der Nutzung eigener Daten zum Modelltraining ist in den höheren Tarifen vorgesehen.

Praktischer Rat: Für Experimente und Prototypen gehören keine echten Personendaten ins System. Testdatensätze mit erfundenen Namen kosten zehn Minuten und ersparen unangenehme Fragen.

Praxisbeispiel: Onboarding-Tool für eine Agentur mit vier Leuten

Eine kleine Agentur betreut etwa 25 laufende Kunden. Das Onboarding neuer Kunden lief bisher über eine Tabelle und viele Mails: Zugangsdaten anfordern, Markenrichtlinien einsammeln, Ansprechpartner klären. Nichts davon ist kompliziert, alles geht regelmäßig unter. Gesucht wird ein internes Tool, in dem jeder Kunde eine Checkliste bekommt, Dateien hochladen kann und das Team den Status sieht.

Der Aufbau in Lovable verläuft typischerweise so:

1. Erster Prompt, rund 10 Min. Beschreibung der Anwendung in fünf, sechs Sätzen: Zweck, Rollen (Agentur-Team und Kunde), die vier Hauptseiten, gewünschter Stil. Ergebnis ist ein klickbares Gerüst mit Beispieldaten.
2. Supabase verbinden, 15 Min. Projekt in der Region Frankfurt anlegen, verbinden, dann die KI anweisen, Tabellen für Kunden, Aufgaben, Dateien und Profile zu erzeugen. Dazu die Anweisung, Row Level Security zu aktivieren, damit ein Kunde ausschließlich seine eigenen Einträge sieht.
3. Nutzer-Login, 20 Min. Registrierung per Mail, Rollenlogik, geschützte Routen. Hier lohnt ein Test mit zwei Browserprofilen: Sieht Kunde B wirklich nichts von Kunde A? Dieser Test wird am häufigsten vergessen.
4. Design angleichen, 20 Min. Logo hochladen, Hausfarben setzen, Schrift tauschen. Der größte Teil davon im visuellen Editor, ohne Credits.
5. Details, 30 Min. Statusfilter, Fortschrittsanzeige in Prozent, automatische Erinnerungsmail nach sieben Tagen Inaktivität über eine Edge Function.

Nach ungefähr anderthalb bis drei Stunden steht eine benutzbare interne Anwendung auf einer Subdomain. Zum Vergleich: Eine Agentur hätte für dieselbe Funktionalität klassisch mehrere Tage Entwicklungszeit kalkuliert. Der Haken liegt woanders. Was in dieser Zeit entsteht, ist ein funktionierendes internes Werkzeug für vier Leute, kein Produkt für 4.000 zahlende Nutzer. Für den Schritt dorthin braucht es Lasttests, saubere Fehlerbehandlung, Backups und jemanden, der den Code verantwortet.

Wo Lovable an Grenzen stößt

Regressionen. Die KI ändert beim Beheben eines Problems gelegentlich Dinge, die funktioniert haben. Je größer das Projekt, desto häufiger. Gegenmittel: kleine Schritte, nach jedem Schritt testen, Versionen als Checkpoints nutzen.

Komplexität. Ab einer gewissen Projektgröße, grob ab mehreren Dutzend Komponenten, verliert die KI den Überblick. Sie legt doppelte Dateien an, ändert an der falschen Stelle oder schlägt Umbauten vor, die alles verschieben. Spätestens dann ist der Export nach GitHub und die Weiterarbeit in einer IDE der ehrlichere Weg.

Sicherheit. 2025 sorgten Analysen für Aufsehen, nach denen ein erheblicher Teil der mit solchen Tools erzeugten Projekte offene Datenbanktabellen hatte, weil Row Level Security nicht oder falsch konfiguriert war. Lovable hat reagiert und prüft Projekte inzwischen auf typische Schwachstellen, bevor sie veröffentlicht werden. Die Verantwortung bleibt trotzdem beim Betreiber. Wer eine Anwendung mit echten Kundendaten online stellt, sollte die Sicherheitsregeln der Datenbank einmal von jemandem prüfen lassen, der SQL lesen kann.

Kosten bei intensiver Nutzung. Wer täglich arbeitet, kommt mit dem Einstiegstarif selten aus. Kalkulieren Sie realistisch mit dem nächsthöheren Paket oder Nachkäufen.

Individualität. Viele Ergebnisse sehen sich ähnlich, weil dieselbe Komponentenbibliothek zum Einsatz kommt. Für eine Marke mit eigenem Design braucht es gezielte Vorgaben, idealerweise eine hochgeladene Vorlage.

Ist Lovable seriös?

Ja, im Sinne von: ein real existierendes Unternehmen mit Sitz in der EU, bekannten Investoren, einer öffentlichen Dokumentation, transparenten Tarifen und einer großen Nutzerbasis. Es gibt keinen Zwang zum Lock-in, weil der Code exportierbar ist und auf verbreiteten Technologien aufsetzt. Das ist ein deutlicher Unterschied zu Plattformen, deren Ergebnis die Plattform nie verlassen kann.

Seriös heißt aber nicht fehlerfrei. Kritik gibt es an Credits, die bei Fehlschlägen trotzdem verbraucht werden, an schwankender Qualität je nach Modellauslastung und an Support-Wartezeiten in den unteren Tarifen. Wer eine geschäftskritische Anwendung plant, sollte das Tool als Beschleuniger der ersten 80 Prozent betrachten und für die restlichen 20 Prozent Budget für einen Entwickler einplanen.

Lovable vs. Bolt, v0 und Replit

Der Markt für diese Art von Software ist dicht besetzt, die Werkzeuge unterscheiden sich im Schwerpunkt.

• Lovable vs. Bolt.new: Bolt gibt mehr Kontrolle über die Umgebung, unterstützt mehr Frameworks und läuft in einer Browser-Entwicklungsumgebung. Lovable ist aufgeräumter und liefert beim Design meist das schönere Erstergebnis.
• Lovable vs. v0 von Vercel: v0 ist stark bei einzelnen Komponenten und Next.js-Oberflächen, weniger bei kompletten Anwendungen samt Datenbank. Wer ein UI-Element braucht, ist dort schnell, wer eine ganze App will, bei Lovable.
• Lovable vs. Replit: Replit ist eine vollwertige Entwicklungsumgebung mit Terminal, mehreren Sprachen und Hosting. Mehr Möglichkeiten, aber auch mehr Einarbeitung. Für Menschen ohne Programmierkenntnisse ist Lovable der leichtere Einstieg.
• Lovable vs. klassisches No-Code: Bubble, Softr oder Glide bieten mehr Stabilität bei Standardfällen und fertige Bausteine, produzieren aber keinen eigenständigen Code. Ein KI-Website-Generator wie Lovable gibt dafür die Dateien heraus.

Für reine Marketing-Seiten ohne Logik bleiben Webflow oder Framer oft die effizientere Wahl. Lovable spielt seine Stärke dort aus, wo eine Website zur Anwendung wird: Login, Daten, Formulare, Auswertungen.

Häufige Fragen zu Lovable

Was kann man mit Lovable konkret machen?

Alles, was sich als Web-App im Browser abbilden lässt: Prototypen für eine neue Geschäftsidee, interne Werkzeuge, Kundenportale, Buchungsseiten, Umfragen, Dashboards mit Diagrammen, kleine Shops mit Stripe-Anbindung. Auch klassische Websites mit mehreren Seiten sind möglich, hier konkurriert das Tool aber mit spezialisierten Baukästen.

Braucht man Programmierkenntnisse?

Für den Einstieg nein. Für alles jenseits des Prototyps hilft Grundverständnis enorm: Was ist eine Datenbanktabelle, was macht eine Umgebungsvariable, warum gehören Berechtigungen auf den Server. Wer das weiß, formuliert bessere Anweisungen und erkennt Fehler früher.

Gehört mir der erzeugte Code?

Nach den Nutzungsbedingungen liegen die Rechte am erzeugten Code bei den Nutzern der bezahlten Tarife. Über die GitHub-Verbindung lässt sich das Projekt jederzeit herunterladen und anderswo hosten, etwa auf Vercel, Netlify oder einem eigenen Server in Deutschland.

Kann ich mit mehreren Personen an einem Projekt arbeiten?

Ja, die bezahlten Tarife erlauben mehrere Mitglieder im Workspace mit gemeinsamem Zugriff auf Projekte. Die Credits werden dabei aus einem gemeinsamen Topf bezogen, was bei einem größeren Team Absprachen nötig macht.

In welcher Sprache gebe ich die Anweisungen ein?

Deutsche Prompts funktionieren. Englisch liefert in der Praxis etwas präzisere Ergebnisse, weil die Modelle darauf trainiert sind und technische Begriffe eindeutiger sind. Die erzeugte Oberfläche lässt sich unabhängig davon in jeder Sprache ausgeben.

Was passiert, wenn ich kündige?

Veröffentlichte Projekte in bezahlten Tarifen gehen mit dem Downgrade zurück in den Free-Status, private Projekte können öffentlich werden. Wer kündigt, exportiert vorher das Repository und sichert die Supabase-Datenbank. Supabase ist ohnehin ein eigener Vertrag und bleibt davon unberührt.

Für wen lohnt sich der Einstieg?

Für alle, die eine Idee schnell testen wollen, statt sie zu beschreiben. Ein Prototyp, den Kunden anklicken können, bringt in einem Gespräch mehr als zehn Folien. Und für kleine Teams, die interne Werkzeuge brauchen, für die nie Budget da war. Wer dagegen eine Anwendung mit tausenden Nutzern, komplexer Abrechnung und strengen Compliance-Anforderungen plant, nutzt Lovable sinnvoll als Startpunkt und holt für den Ausbau Entwickler dazu.