PHASE 01Video folgt

Grundlagen

Bevor du das erste Mal „Build me an app“ in einen Builder tippst, lohnt sich ein klarer Blick auf drei Dinge: Was eine vollwertige App eigentlich ausmacht, welche Tools zur Erstellung genutzt werden können, und was einen guten Prompt ausmacht.

0:00 / 0:00

1. Was eine vollwertige App beinhaltet

Eine Full-Stack-App ist eine Anwendung, die den kompletten technischen Stack (also den ganzen Stapel an Technologien, von Oberfläche bis Datenbank) eines digitalen Produkts abdeckt: nicht nur eine sichtbare Oberfläche, sondern das gesamte System dahinter. In der Regel gehören dazu:

Frontend: die Oberfläche, mit der Nutzer direkt interagieren.
Backend: die Logik und Datenverarbeitung im Hintergrund.
Datenbank: zur Speicherung von Informationen.
Authentifizierung: Login, Registrierung, Sessions.
Zusatzbausteine: Zahlungen, E-Mails, Analytics, Automatisierungen.

Sobald deine Anwendung mehr sein soll als eine Hintergrundautomatisierung, braucht sie ein Frontend. Eine bewährte Basis ist React für die Oberfläche, aufgebaut aus wiederverwendbaren Komponenten (Buttons, Cards, Formulare). Dazu kommen meist TypeScript für robusteren Code und Tailwind CSS für konsistentes Styling.

Bei neuen Lovable-Projekten kommt dazu ein technisches Fundament, das Seiten besser lesbar ausliefert (TanStack Start mit serverseitigem Rendering). Praktisch heißt das: Deine App bleibt React, aber Google und KI-Crawler können wichtige Inhalte früher und zuverlässiger lesen.

Wichtig: Du musst diese Technologien nicht beherrschen und auch nicht im Detail kennen. AI-Builder und AI-IDEs wählen Bibliotheken, schreiben den Code und kümmern sich um das Zusammenspiel im Hintergrund. Trotzdem lohnt es sich, den bevorzugten Stack einmalig im Initial Prompt festzulegen (das ist der allererste, große Anweisungstext, mit dem du dem Builder deine App-Idee, deinen Stack und die wichtigsten Regeln auf einmal mitgibst). Eine konkrete Vorlage dafür kommt in Phase 2.

Damit eine App im Internet erreichbar ist, braucht sie Hosting. Bei Buildern wie Lovable ist das integriert, du musst dich am Anfang nicht selbst darum kümmern. Über eine API (Schnittstelle, über die zwei Programme miteinander reden) kann deine App mit anderen Systemen sprechen, etwa mit Stripe für Zahlungen oder mit OpenAI für KI-Funktionen.

Für das Backend brauchst du selten alles selbst zu bauen. Es gibt fertige Dienste für Datenbank und Authentifizierung (z. B. Supabase), für Zahlungen (Stripe), für E-Mail-Versand (Resend) und für Automatisierungen (n8n). Alle lassen sich direkt aus dem Builder-Chat anbinden, oft mit einem einzigen Satz. Was hinter den Begriffen genau steckt, vertiefen wir in den späteren Phasen, wenn du sie tatsächlich brauchst.

2. Die AI-Toollandschaft: nach Rollen verstehen

Die Tool-Landschaft wirkt schnell überwältigend. Ich erkläre dir vier wichtige Kategorien, das reicht für den Einstieg.

AI-Builder

Lovable, Bolt, Replit, Figma Make. Steuerung über natürliche Sprache, erzeugen direkt Software und übernehmen meistens auch das Hosting. Ideal für den Start, für MVPs (Minimum Viable Product, also die kleinste lauffähige Version eines Produkts, mit der echte Nutzer schon arbeiten können) und für alle, die schnell in eine lauffähige Version kommen wollen.

AI-IDEs

Cursor, Claude Code, Windsurf. Eine IDE ist eine Entwicklungsumgebung. Moderne AI-IDEs lassen sich ebenfalls per Sprache steuern, geben aber deutlich mehr Kontrolle über einzelne Dateien und Architekturentscheidungen. Sinnvoll, wenn das Projekt größer wird oder gezielte Eingriffe nötig sind.

AI-Workflow-Tools

n8n, Make, Zapier. Lösen nicht das Bauen der App, sondern wiederkehrende Prozesse im Hintergrund: Webhooks, Benachrichtigungen, Agentenketten. Wenn ein Workflow-Tool eine Aufgabe einfacher und robuster abbildet als eigener Code, ist es meist die bessere Wahl.

AI-native Backends & Mail-Services

Supabase, Firebase, PocketBase, Resend. Lassen sich gut an Builder und AI-IDEs anbinden, oft direkt aus dem Entwicklungsprozess heraus konfigurieren.

MCP & Connectors: der unsichtbare Klebstoff

Connectors bedeuten zuerst einmal: Du musst weniger kopieren, weniger geheime Schlüssel manuell einbauen und weniger zwischen Dashboards hin- und herspringen. Der Builder bekommt kontrollierten Zugriff auf ein Tool und kann geführte Schritte direkt aus dem Chat anstoßen.

Die technische Klammer dahinter heißt MCP (Model Context Protocol). Das ist ein offener Standard, über den KI-Systeme strukturiert auf externe Tools, Datenquellen und Kontexte zugreifen können, ohne dass du Endpunkte, Auth-Flows oder Datenformate für jedes Tool selbst verdrahten musst. Connectors sind die vorkonfigurierten Integrationen, die Lovable (und andere Builder/IDEs) auf dieser Basis anbieten.

Praktischer Nutzen: Builder und AI-IDEs verstehen mehr echten Projektkontext, Copy-Paste fällt weg, und Sätze wie „Verbinde Supabase", „Leg in Linear ein Issue an" oder „Lies die Spec aus Notion" funktionieren direkt aus dem Chat. Du musst in der Regel nur einmalig die Secrets / den Login hinterlegen, den Rest übernimmt der Connector.

Warum das von Anfang an wichtig ist

Viele Tools (z. B. Supabase, Stripe, Resend, n8n, Notion, Linear, Sentry, PostHog) kannst du direkt aus dem Lovable- oder Cursor-Chat anbinden, über Connectors oder MCP-Server. In den folgenden Phasen markieren wir je Tool, wo das gilt. Damit kannst du massiv Zeit sparen.

Beispiel-Stack & Kosten (grobe Hausnummern, Stand: Frühjahr 2026)

Lovable: initiales Setup & Hosting · ca. 50 €/Monat
Supabase: erstes Projekt free · ggf. 10 €/Monat für Custom Domain
Resend: erstes Projekt free
PostHog: erstes Projekt free
ChatGPT: free, Plus-Abo empfohlen
Cursor oder Claude Code: optional, je 20 €/Monat (eines reicht)
Stripe: % nach Umsatz

Preise und Tarife ändern sich häufig. Vor dem Buchen kurz auf den Anbieter-Seiten gegenchecken.

3. Prompting & LLM-Grundlagen

Du musst kein Informatiker werden, solltest aber verstehen, wie die Systeme grob funktionieren. Ein Prompt ist die Arbeitsanweisung an ein Sprachmodell. Je präziser der Kontext und je klarer die Aufgabe, desto höher die Chance auf eine brauchbare Antwort. Ein guter Prompt ist nicht einfach lang, sondern zielgerichtet.

Ein LLM (Large Language Model) ist keine klassische Wissensdatenbank. Es berechnet Wahrscheinlichkeiten für das nächste passende Textelement (genannt „Token"). Daraus folgt für die Praxis: Ein LLM klingt oft sehr sicher, auch wenn eine Aussage nicht sauber belegt ist. Kritische Aussagen also immer prüfen.

Was ist ein Token?

Ein Token ist die kleinste Verarbeitungseinheit eines Sprachmodells, ungefähr ein Wortteil. „Hallo Welt" sind etwa 3 Tokens. Praktische Konsequenz: Längere Prompts und Antworten kosten mehr Tokens, also auch mehr Geld und Rechenzeit. Modelle haben außerdem ein Token-Limit pro Anfrage. Sehr lange Dokumente musst du ggf. in Stücken übergeben.

Die vier Bausteine eines guten Prompts

Rolle: z. B. „Senior Product Manager", „UX-Researcher", „Senior Engineer".
Aufgabe: klar formuliert, etwa „scopiere diese Idee zu einem MVP" oder „formuliere diesen Text verständlicher für kleine Agenturen".
Kontext: Zielgruppe, Branche, technische Grenzen, Beispiele oder Dateien.
Output-Regeln: Stichpunkte, Executive Summary, Tabelle, priorisierte Handlungsempfehlungen.

Praxis-Regeln

Setze die eigentliche Arbeitsanweisung früh im Prompt.
Trenne Aufgabe und Kontext klar voneinander.
Beschreibe das gewünschte Format explizit.
Nutze Beispiele, wenn Stil oder Struktur wichtig sind.
Arbeite iterativ. Ein erster Prompt liefert die Rohfassung, ein zweiter die Schärfung, ein dritter die produktionsnahe Version.

Wie LLMs typisch danebenliegen

Ein paar Effekte tauchen so regelmäßig auf, dass es sich lohnt, sie als Grundwissen mitzunehmen. Wer sie kennt, baut bessere Prompts und stolpert seltener über scheinbar souveräne, aber falsche Antworten.

Continuation Bias: Modelle setzen ein Gespräch lieber fort, als zu sagen „ich weiß es nicht" oder „mir fehlen Infos". Daraus entstehen plausibel klingende, aber falsche Antworten. Gegenmittel: explizit erlauben, „keine Antwort möglich" zu sagen, und Rückfragen einfordern.
Sycophancy (LLMs geben Recht): Modelle stimmen Nutzern oft eher zu, als klar zu widersprechen. Wenn du ehrliches Feedback willst, frag explizit nach Schwächen, Risiken oder Gegenargumenten, statt nach „Was hältst du davon?".
Attention steuern mit GROSSBUCHSTABEN: Wirklich wichtige Regeln in einem langen Prompt landen oft trotzdem im Rauschen. Wenn etwas zwingend eingehalten werden soll, hilft eine Hervorhebung wie „WICHTIG: niemals X tun" sichtbar mehr als ein freundlicher Nebensatz.
„Only" statt „Don't": Modelle ignorieren Verneinungen häufiger als positive Anweisungen. „Don't use red" landet schnell trotzdem bei Rot. Besser: „Only use these colors: ...". Statt auszuschließen, was nicht passieren soll, beschreibe, was genau passieren soll.

4. Beispielprojekte aus der Praxis

Damit das Ganze nicht abstrakt bleibt, hier ein paar Apps, die ich selbst mit genau diesem Vorgehen gebaut habe. Sie reichen vom kleinen Tool bis zum kompletten SaaS und zeigen die Bandbreite, was mit dem hier beschriebenen Stack realistisch ist.

Nächster Schritt

Du kennst jetzt die Bausteine, die Tool-Kategorien und die Prompt-Logik. Im nächsten Schritt geht es darum, daraus eine konkrete Idee zu schärfen und zum Initial Prompt zu kommen.

Weiter zur Startphase