MVP entwickeln 2026: Prototyp oder MVP, Ablauf in Wochen, Kosten und Grenzen von Lovable

Mit Lovable entsteht aus ein paar Sätzen im Chat eine klickbare Web-App, die aussieht wie ein fertiges Produkt. Genau deshalb ist die Trennung zwischen Prototyp und MVP heute wichtiger als früher: Was fertig aussieht, ist noch lange nicht bereit für echte Kundendaten.

Was ist der Unterschied zwischen Prototyp und MVP?

Ein Prototyp prüft, ob Menschen deine Lösung verstehen und bedienen können. Ein MVP (Minimum Viable Product, die kleinste brauchbare Version eines Produkts) prüft, ob echte Kunden sie im Alltag nutzen oder dafür bezahlen. Eric Ries hat das MVP 2009 als die Version beschrieben, mit der ein Team mit dem geringsten Aufwand das meiste belastbare Wissen über seine Kunden sammelt. Es geht also nicht um das kleinstmögliche Produkt, sondern um den günstigsten Weg zu einer belastbaren Antwort.

Mit Lovable verschwimmt diese Grenze. Ein Prototyp bekommt dort schnell Login und Datenbank, weil das Werkzeug beides auf Zuruf einbaut. Das ist praktisch, wird aber riskant, sobald jemand echte Kundendaten einträgt: Ab dann gelten die Regeln eines MVP, egal wie die App entstanden ist.

Wie läuft eine MVP-Entwicklung in Wochen statt Monaten ab?

Vier bis acht Wochen sind realistisch, wenn drei Dinge feststehen: eine Hypothese in einem Satz, ein hart begrenzter Funktionsumfang und zwei feste Entscheidungspunkte. Ein realistischer Ablauf:

1. Vorbereitung, zwei bis drei Tage: Schreib die Hypothese auf, zum Beispiel „Handwerksbetriebe erfassen Arbeitszeiten lieber per Smartphone als auf Papier“. Leg vorher fest, ab welcher Zahl du weitermachst, etwa: Sechs von zehn Pilotbetrieben nutzen die App nach vier Wochen noch jede Woche. Dazu kommt eine Nicht-Liste mit allem, was ausdrücklich nicht ins MVP gehört.
2. Woche 1 bis 2, Prototyp: Klickbare Oberfläche mit Beispieldaten, ohne echte Datenbank. Teste mit fünf Personen, bessere nach, teste erneut. Jakob Nielsen rät seit dem Jahr 2000 zu drei Runden mit je fünf Personen statt einer großen Studie, weil sich nach dem fünften Nutzer die Befunde wiederholen. Entscheidungspunkt 1: Verstehen die Testpersonen den Kernablauf ohne Erklärung? Wenn nicht, nachbessern oder die Idee verwerfen.
3. Woche 2 bis 4, MVP-Kern: Genau ein Ablauf von Anfang bis Ende, mit echter Datenbank, Login und Rollen (wer darf was). Zugriffsregeln, Datenregion, Backups und eigene Domain gehören in diese Phase, nicht auf die Später-Liste.
4. Woche 4 bis 5, prüfen und live gehen: Sicherheitsscan, Test mit zwei Konten (siehe Fehler weiter unten), Datenschutzerklärung, dann die Pilotnutzer einladen.
5. Woche 5 bis 8, messen und entscheiden: Vergleiche die Nutzung mit der Zahl aus der Vorbereitung. Entscheidungspunkt 2: ausbauen, umbauen oder stoppen. Auch ein Stopp ist ein Ergebnis, nur eben nach acht Wochen statt nach einem Jahr.

So gehen wir auch bei unseren Web-App-Projekten vor: Audit (Bestandsaufnahme), Konzept mit festem Umfang, Umsetzung in Sprints (kurzen, festen Arbeitsabschnitten) mit wöchentlichem Update, Livegang mit Dokumentation, danach Optimierung. Projekte dauern bei uns typischerweise zwei bis acht Wochen, und wir gehen lieber nach vier Wochen live als nach einem halben Jahr Planung.

Was können Lovable und Supabase heute, und wo hören sie auf?

Lovable baut aus Beschreibungen im Chat eine lauffähige Web-App, und Lovable Cloud, das eingebaute Backend (alles hinter der Oberfläche), liefert Datenbank, Login, Dateispeicher, Serverfunktionen und KI-Funktionen gleich mit. Serverfunktionen sind Programmteile, die auf dem Server statt im Browser laufen, etwa für Zahlungen oder Schnittstellen. Lovable Cloud beruht auf der Open-Source-Technik von Supabase, einem Backend-Dienst, den du auch direkt buchen kannst. Dazu kommen E-Mail-Funktionen, geplante Aufgaben, ein Tresor für Zugangsschlüssel und Protokolle. Vor dem Veröffentlichen läuft automatisch ein Sicherheitsscan, ein gründlicherer Scan prüft unter anderem Zugriffsrechte, Schnittstellen ohne Login, unsichere Eingaben, Zahlungen und offen liegende Zugangsschlüssel.

Für einen Prototyp ist das mehr als genug. Bei einem MVP stößt du an fünf Stellen an Grenzen:

• Sicherheit bleibt deine Aufgabe. Lovable schreibt selbst, die Scans fänden häufige Probleme, könnten aber keine vollständige Sicherheit garantieren. Verantwortlich für die Sicherheit deiner App bist laut Doku du, bei sensiblen Daten empfiehlt Lovable eine zusätzliche professionelle Prüfung. Wie ernst das ist, zeigt der Eintrag CVE-2025-48757 vom 30. Mai 2025: Wegen unzureichender Row Level Security (RLS, Regeln in der Datenbank, die festlegen, wer welche Zeile lesen oder ändern darf) konnten Angreifer bei betroffenen, mit Lovable erzeugten Apps ohne Login beliebige Tabellen lesen oder beschreiben. Betroffen war der Stand bis zum 15. April 2025, die Bewertung nach dem Standard CVSS: 9,3 von 10 Punkten, Stufe kritisch. Lovable widerspricht dem Eintrag mit dem Argument, jeder Kunde sei selbst für den Schutz der Daten seiner App verantwortlich. Für dich läuft beides auf dasselbe hinaus: Prüfen musst du selbst.
• Die Datenregion ist eine Einbahnstraße. Lovable Cloud bietet die Regionen Amerika, Europa und Asien-Pazifik. Nach dem Aktivieren lässt sich die Region nicht mehr ändern, und bestehende Projekte lassen sich nicht in eine andere Region verschieben. Arbeitest du mit personenbezogenen Daten aus der EU, ist Europa meist die naheliegende Wahl, und zwar vor dem ersten Datensatz.
• Der Umzug ist Handarbeit. Von Lovable Cloud in ein eigenes Supabase-Projekt gibt es laut Doku keinen Umzug per Klick, der Export läuft manuell. Den umgekehrten Weg unterstützt Lovable derzeit nicht. Willst du die Daten langfristig selbst verwalten, entscheide das vor dem Start.
• KI-Training ist in Free und Pro nicht automatisch aus. Dass die Daten deines Workspace (des gemeinsamen Arbeitsbereichs in Lovable) nicht ins Training von KI-Modellen fließen, ist erst ab dem Business-Tarif Standard. In Free und Pro musst du es pro Account abwählen. Bei vertraulichen Produktideen erledigst du das vor dem ersten Prompt.
• Komplexe Logik braucht jemanden, der den Code liest. Unsere Einschätzung: Bei Formularen, Listen und Dashboards kommt Lovable sehr weit. Sobald Abrechnungsregeln, Schnittstellen zu ERP-Systemen (Software für Einkauf, Lager und Buchhaltung) oder viele Rollen mit unterschiedlichen Rechten dazukommen, schreibt die KI zwar weiter Code, aber jede Änderung kann an anderer Stelle etwas brechen. Ohne jemanden, der den Code versteht und prüft, wird jede weitere Anfrage an die KI zum Glücksspiel.

Was kostet ein MVP 2026 realistisch?

An Werkzeugen zahlst du im Pilotbetrieb je nach Tarif und Zahlweise etwa 21 bis 75 US-Dollar im Monat, der große Posten ist Arbeitszeit für Konzept, Prüfung und Nachbessern. Lovable rechnet in Credits ab, einer eigenen Verrechnungseinheit für Aufträge an die KI. Die Tarife laut Lovable und Supabase, Stand 5. Oktober 2026:

Lovables Preisseite nennt Beispiele: Eine kleine Änderung wie „mach den Button grau“ kostet 0,50 Credits, eine Landingpage mit Bildern 1,70. 100 Credits reichen damit für grob 60 bis 200 solcher Aufträge im Monat, dazu kommen die fünf täglichen. Nachkaufen kostet im Pro-Tarif 15 US-Dollar je 50 Credits. Abgerechnet wird nicht pro Kopf: Ein Workspace hat in allen Tarifen beliebig viele Mitglieder.

Läuft das Backend über Lovable Cloud, sind 20 Cloud-Credits im Monat inklusive, Lovable nennt diese Freikontingente ausdrücklich vorübergehend. Läuft die App auf einem eigenen Supabase-Projekt, gilt dessen Tarif. Für Pilotnutzer solltest du dort Pro nehmen: Ein Projekt, das nach einer Woche Ruhe pausiert und keine Backups hat, ist für echte Nutzer ungeeignet. Rechenbeispiel bei monatlicher Zahlung: Lovable Pro mit Lovable Cloud kostet 25 US-Dollar, Lovable Pro plus Supabase Pro 50 US-Dollar, mit Business statt Pro 75 US-Dollar, jeweils plus Nachkäufe.

Unsere Einschätzung: Teuer werden nicht die Tarife, sondern Fehlerschleifen, in denen die KI etwas repariert und dabei etwas anderes bricht. Jede Runde kostet Credits und vor allem Zeit. Eine klare Nicht-Liste spart mehr als jeder Tarifvergleich. Bei uns starten Web-Apps ab 5.000 Euro, als Festpreis oder nach Stunden, die Schätzung vorab ist kostenlos. Ob sich ein Projekt fördern oder günstig finanzieren lässt, hängt vom Programm ab. Die Wege für Niedersachsen haben wir in unserem Überblick zu Förderwegen nach dem Digitalbonus zusammengestellt.

Welche Fehler machen ein MVP teuer?

Die teuren Fehler passieren selten im Code, sondern davor und danach. Die häufigsten, jeweils mit Gegenmittel:

• Den Prototyp für ein MVP halten. Begeisterte Testpersonen sagen nichts darüber, ob jemand zahlt. Gegenmittel: vor jedem Test die Leitfrage aus der Tabelle oben aufschreiben.
• Kein Erfolgskriterium vorab. Ohne vorher festgelegte Zahl lässt sich nach dem Pilot jedes Ergebnis schönreden. Gegenmittel: die Zahl in der Vorbereitung festlegen und danach nicht mehr verschieben.
• Zu viel Umfang. Mit KI ist eine Funktion schnell gebaut, aber jede zusätzliche muss getestet, abgesichert und gepflegt werden. Gegenmittel: Jede neue Idee kommt zuerst auf die Nicht-Liste.
• Zugriffsregeln nicht geprüft. Im schlimmsten Fall passiert, was CVE-2025-48757 beschreibt: Fremde lesen oder ändern Kundendaten, ohne sich anzumelden. Bei personenbezogenen Daten ist das ein Datenschutzvorfall, kein Schönheitsfehler. Gegenmittel: Sicherheitsscan laufen lassen, dann jede Tabelle durchgehen (wer darf lesen, anlegen, ändern, löschen?) und mit zwei Testkonten prüfen, ob Konto B irgendwo Daten von Konto A sieht.
• Gratistarif im Pilotbetrieb. Ein Supabase-Projekt im Free-Tarif pausiert nach einer Woche ohne Aktivität, Backups gibt es keine. Bei wenigen Pilotnutzern reicht eine ruhige Ferienwoche, und die App steht still. Gegenmittel: ab dem ersten echten Nutzer Pro.
• Region und Umzug nicht entschieden. Die Region lässt sich bei Lovable Cloud später gar nicht mehr ändern, der Umzug in ein eigenes Supabase-Projekt geht nur von Hand. Gegenmittel: beides vor dem ersten echten Datensatz festlegen.
• Kein Plan für danach. Unsere Einschätzung: Wer nach dem Pilot ausbauen will, braucht Antworten auf drei Fragen. Wer betreibt die App? Wer prüft Änderungen, bevor sie live gehen? Wer reagiert, wenn am Wochenende etwas ausfällt?

Was heißt das für dich?

Fang mit der Frage an, nicht mit dem Werkzeug. Je nach Stand heißt das:

• Du hast eine Idee, aber noch mit keinem Nutzer gesprochen: Bau einen Prototyp mit Beispieldaten, dafür reicht Lovable Free oder Pro. Zwei bis drei Testrunden mit je fünf Personen bringen dir mehr als jede zusätzliche Funktion.
• Interessenten bestätigen das Problem: Jetzt lohnt das MVP. Plane vier bis acht Wochen ein, nimm die Pro-Tarife, wähle die Datenregion bewusst und prüfe die Zugriffsregeln vor dem Livegang.
• Es geht um Kundendaten, Zahlungen oder die Anbindung an bestehende Systeme: Hol dir vor dem Livegang jemanden dazu, der Code und Datenbankregeln prüfen kann. Lovable empfiehlt das bei sensiblen Daten selbst.
• Es ist ein internes Werkzeug für dein Team: Es gelten dieselben Regeln, nur der Kreis ist kleiner. Auch intern sollte nicht jeder alles sehen, etwa Gehälter oder Kundendaten anderer Abteilungen.

Wenn du das nicht allein bauen willst: Wir entwickeln Web-Apps, interne Dashboards und Kundenportale mit Lovable und Supabase, von der Hypothese bis zum Pilotbetrieb. Schreib uns, die Aufwandsschätzung ist kostenlos.