Startphase
Bevor du den ersten Builder öffnest: Idee schärfen, Wettbewerb verstehen, Scope eingrenzen, Design grob vorbereiten und einen sauberen Initial Prompt formulieren.
1. Eigenes Problem als Startpunkt
Die meisten guten Produktideen entstehen nicht im luftleeren Raum. Mein bevorzugter Startpunkt ist ein eigenes Problem. Welche Aufgabe nervt mich regelmäßig? Welcher Prozess ist unnötig umständlich? Welche Lücke merke ich in meinem Alltag oder in meiner Arbeit?
Ein eigenes Problem zu lösen ist deshalb stark, weil du den Use Case wirklich verstehst und schnell einschätzen kannst, ob die Lösung einen echten Wert hat. Wenn du deine eigene zukünftige App nicht selbst nutzen würdest, ist das für mich ein klares Warnsignal.
Reddit & LinkedIn als Problem-Radar
Reddit und LinkedIn werden im Marketing oft genannt, sind aber auch hervorragende Quellen für die Ideenfindung. Auf Reddit findest du in Subreddits zu deinem Thema sehr ehrliche Beschwerden, Workarounds und „warum gibt es das eigentlich nicht"-Kommentare. Auf LinkedIn siehst du, welche Probleme Menschen in deinem Berufsumfeld öffentlich diskutieren, inklusive Branche und Rolle. Ich gehe gezielt mit Suchbegriffen wie „I wish there was a tool for ...", „frustrating", „manual process" oder „why is X so painful" durch und sammle wiederkehrende Muster.
2. Marktrecherche mit ChatGPT & Perplexity
Für eine erste Marktrecherche kannst du ChatGPT oder Perplexity gut nutzen. Wichtig dabei: Frag nach Kritik, nicht nur nach Chancen.
Gute Fragen sind zum Beispiel:
- Welche Beschwerden haben Nutzer besonders häufig über Tool X?
- Welche Zielgruppe wird unterversorgt?
- Welche Teilfunktion könnte man deutlich einfacher, schneller oder fokussierter lösen?
Das hilft dir, nicht nur „noch eine App" zu bauen, sondern eine saubere Ausgangsposition zu finden.
Typische Denkfehler von LLMs kennen
Einfacher Konzept-Workflow
Formuliere deine Idee frei als Rohtext, füge sie in ChatGPT oder Claude ein und lass sie in klare Produktsprache übersetzen. Danach aus der Perspektive von Produktmanagement, Design oder Entwicklung darauf schauen.
Bei Research vorher klären: Was willst du am Ende verstehen oder entscheiden? Welche Region und Zeitspanne sind relevant? Welche Quellen bevorzugst du? In welchem Format soll das Ergebnis ausgegeben werden?
Passende Vorlagen für Research, Konzept und PRD findest du in der Prompt-Bibliothek. Einfach kopieren, Platzhalter ersetzen und in ChatGPT oder Claude einsetzen.
3. Scoping — Kernfunktion vs. Nice-to-have
Scope bedeutet: der Umfang dessen, was ein Produkt oder Feature leisten soll. Scoping ist die Tätigkeit, diesen Umfang bewusst einzugrenzen. Das ist einer der wichtigsten Schritte überhaupt. Viele Produkte scheitern an zu viel Umfang zu früh, nicht an zu wenig Potenzial. Unterscheide immer klar zwischen:
Kernfunktion
Der Teil, ohne den das Produkt keinen Sinn ergibt.
Nice-to-have
Sinnvoll, aber nicht release-kritisch. Spätere Ausbaustufe.
Beispiel IndieTasks.app: Kernfunktion sind die Kanban-Boards. Teams, Anhänge und Echtzeit-Kommentare sind dagegen spätere Ausbaustufen.
4. Design vorbereiten: erst Struktur, dann Schönheit
Ein Wireframe ist eine bewusst grobe, meist grau-weiße Skizze der Seiten und Elemente: Boxen, Platzhalter, Anordnung, ohne finale Farben oder Bilder. Tools dafür: Figma, Excalidraw oder einfach Stift und Papier. Davon zu unterscheiden ist ein Mockup: eine deutlich detailliertere, visuell ausgearbeitete Version, die schon nahe am späteren Design ist. Wireframes zuerst, Mockups später. Danach folgt ein einfaches Design-System (eine kleine Sammlung von Regeln und wiederverwendbaren Bausteinen) mit Farben, Abständen, Buttons und Typografie.
Design-Inspiration sammeln
Bevor du dem Builder eine Design-Sprache vorgibst, lohnt sich gezieltes Sammeln statt vager Begriffe wie „modern" oder „clean". Je konkreter deine Referenzen, desto näher landet das Ergebnis an deiner Vorstellung. Der Builder School PRD-Generator enthält dafür 30 kuratierte Design-Inspirationen, die du direkt als Referenz übernehmen kannst.
Screenshots & Referenz-URLs
Konkrete Screenshots oder Links direkt in den Builder geben mit klarer Anweisung, was übernommen werden soll (Layout, Farbpalette, Spacing) und was bewusst nicht.
Kuratierte Design-Quellen in den Ressourcen
Eine sortierte Sammlung der besten Quellen findest du im Ressourcen-Bereich: Mobbin, Dribbble, 21st.dev, Coolors.co, Designprompts.dev, Google Fonts, Fontshare, React Bits und Brandfetch.
Zu den Ressourcen5. User Journey bestimmen
In dieser Phase ist KI als Produktmanager sehr nützlich. Lass dir helfen, Ideen zu schärfen, Funktionen zu priorisieren, Risiken zu benennen und ein PRD zu erstellen.
User Journey & Happy Path
Die User Journey beschreibt den Weg eines Nutzers vom ersten Einstieg bis zum Ziel. Gute Fragen:
- Wo kommt der Nutzer rein?
- Was ist seine erste Aufgabe?
- Welche Schritte braucht er?
- Wo könnte er abbrechen?
- Was ist der Aha-Moment?
Unterscheide früh zwischen Happy Path (idealer Standardablauf, alles klappt wie gedacht) und Edge Cases (Sonder- oder Fehlerfälle, z. B. „Was passiert, wenn der Nutzer offline ist?", „Was, wenn jemand zwei Anträge für denselben Tag stellt?", „Was, wenn die Zahlung mittendrin abbricht?"). Wer das früh sauber denkt, baut später robuster.
6. PRD (Initial Prompt) anfertigen
Aus PRD und User Journey entsteht der Initial Prompt für den Builder. Er ist die Grundlage, auf der dein erstes Build aufsetzt.
Was ist ein PRD?
PRD-Generator der Builder School nutzen
Statt bei null anzufangen, kannst du Ziel, Nutzer, Scope und zentrale Flows interaktiv durchgehen und dir ein sauberes PRD generieren lassen. Das Ergebnis eignet sich direkt als Grundlage für deinen Initial Prompt.
Zum PRD-GeneratorEin guter Initial Prompt für einen Builder sollte enthalten:
Stack bedeutet hier: die Tools, mit denen deine App gebaut wird. Eine einfache Beispielzeile reicht am Anfang: „App in Lovable bauen, Login und Datenbank über Supabase, E-Mail über Resend, Zahlungen über Stripe."
Bei neuen Lovable-Projekten ist die bessere Auslieferung für Google und KI-Crawler bereits Teil des technischen Fundaments (TanStack Start mit SSR). Du musst das nicht in den Prompt schreiben, solltest es aber beim Thema SEO im Hinterkopf behalten.
- · Problem & Zielgruppe
- · Kernnutzen
- · Hauptseiten
- · Kernfunktion
- · Spätere Funktionen (klar als „später" markiert)
- · Design-Vibe, Farben, Tonalität
- · No-Gos
- · Bevorzugter Stack
Erst wenn diese Dinge klar sind, würde ich den Builder öffnen.
Warum der Initial Prompt so wichtig ist
Um den Unterschied greifbar zu machen, hier eine kleine Übung, die ich die „One-Prompt-Challenge" nenne: Denselben Use Case mit nur einem einzigen Prompt bauen, aber zwei Mal mit unterschiedlich viel Vorbereitung. Als Beispiel habe ich einen realistischen Fall für kleinere Unternehmen gewählt, einen Urlaubsantrag & Abwesenheitskalender, und ihn in einem AI-Builder zwei Mal gebaut. Die richtigen Tools geben dir heute die volle Power für deine nächste App. Aber ohne das richtige Vorgehen wird's trotzdem nichts.
Vibe Coding
Vibe Coding heißt: einfach drauflos prompten, ohne Konzept, ohne Rollen, ohne Edge Cases. So komplex ist der Use Case doch nicht. Der erste Prompt bestand aus drei Sätzen, ca. 50 Wörter.
Ergebnis: besser als erwartet, aber nicht wirklich nutzbar. Keine echte Rollentrennung, jeder konnte im Dropdown das Freigeber-Profil wählen, auf Mobile waren Buttons verschwunden. Heißt: viel Rework, also Zeit und Geld.
Prototyping mit Konzept
Initial Prompt als Blueprint: Funktionen und Flows beschrieben, Rollen definiert (Employee/Manager/Admin), Zustände modelliert (Draft → Submitted → Approved/Rejected → Cancelled), Datenmodell, Edge Cases (Überschneidungen, Resturlaub, Halbtage, Feiertage) und Design-Sprache. Ca. 4.000 Wörter, davon ein Teil wiederverwendbares Framework.
Ergebnis: konsistentes, modernes Design mit echter Detailtiefe: dedizierte Admin-Seiten für Feiertage und Rollen, getrennte Bereiche je Rolle, übergreifendes Dashboard und eine responsive UI, die auch auf Mobile sauber funktioniert.
Vibe Coding (~50 Wörter)
40 Wörter
Prototyping mit Konzept (~1.000 Wörter)
998 Wörter
Und das ist erst der Anfang: in diesem Beispiel habe ich bewusst nur mit Mock-Daten gearbeitet. Mit Backend, echter Profil-Integration und Security-Aspekten würde die Schere noch deutlich weiter aufgehen.
7. Lovable als AI-Builder für dein MVP
Du hast jetzt Idee, Scope, PRD, User Journey und eine grobe Design-Richtung. Bevor wir gleich den Initial Prompt formulieren, kurz das Werkzeug, in das er reingeht: Lovable ist ein All-in-one AI-Builder, der den kompletten Weg von deinem Initial Prompt über Frontend, Backend, Authentifizierung und Edge Functions bis hin zum Hosting unter einer eigenen Domain abdeckt. Du musst also nicht zwischen fünf verschiedenen Tools jonglieren, um eine funktionierende App live zu bekommen.
Für neue Projekte nutzt Lovable außerdem eine Technik, die Seiten schon besser lesbar ausliefert (TanStack Start mit SSR). Das ist vor allem für Auffindbarkeit bei Google und KI-Suchsystemen relevant, nicht für deinen Alltag beim Prompten.
Ein zentraler Vorteil sind die vielen integrierten Connectoren: Stripe für Zahlungen, Resend für E-Mails, GitHub für Versionierung, Custom Domains und diverse APIs über MCP. Das spart dir massiv Konfigurationszeit und reduziert Fehlerquellen.
Für das Backend bietet Lovable mit Lovable Cloud (basiert auf Supabase) eine direkt integrierte Lösung. Diese eignet sich gut für ganz kleine oder interne Apps, etwa Prototypen, Tools für ein kleines Team oder schnelle MVPs. Sobald deine App ernsthaft wachsen oder produktiv mit vielen externen Nutzern laufen soll, ist eine direkte, eigene Supabase-Anbindung die robustere Wahl (mehr dazu in der MVP-Phase).
Wichtig: Ein Wechsel von Lovable Cloud zu einer eigenen Supabase-Instanz ist im Nachhinein nicht mehr möglich. Ich empfehle daher, direkt mit einer echten Supabase-Anbindung zu starten. Lovable fragt dich zu Beginn deines Projekts, welchen Weg du nutzen möchtest.
Gearbeitet wird in zwei Modi: dem Plan-Modus zum Schärfen von Vorhaben und dem Build-Modus zum tatsächlichen Bauen (mehr zu Credits gleich im nächsten Abschnitt). Für ein erstes MVP ist diese Kombi ideal: schneller Feedback-Loop durch die sichtbare Preview und ein sauberer Übergang vom Prototyp zur produktiven App.
Erstelle dir für den weiteren Verlauf nun ein Konto
Benutze den Link und erhalte 10 Credits on top zum Loslegen.
Konto bei Lovable erstellen8. Kosten & Credits in der Praxis
Lovable rechnet pro Nachricht in Credits ab. Wer iterativ in kleinen Schritten arbeitet, verbraucht messbar weniger als bei langen Riesen-Prompts.
Im Free-Plan bekommst du 5 tägliche Credits (gedeckelt auf 30 pro Monat). Das reicht zum Reinschnuppern und für ein erstes Gefühl. Sobald du ernsthaft an einem Projekt baust, brauchst du den Pro-Plan (Stand Frühjahr 2026: rund 25 USD/Monat für 100 Credits, also grob 25 Cent pro Credit). Realistische Hausnummer für eine erste eigene App: rund 50 bis 100 Credits, je nach Umfang und wie sauber du prompted.
Lovable Cloud wird separat abgerechnet und basiert auf Supabase (mehr dazu in den späteren Phasen dieses Guides). Du bekommst pro Monat 25 USD Cloud-Guthaben und 1 USD AI-Guthaben geschenkt, alles darüber läuft nutzungsbasiert.
Nächster Schritt
Mit klarem Scope und Initial Prompt geht's in die MVP-Phase: Lovable, Supabase, Auth und der erste lauffähige Build.
Weiter zur MVP-Phase