Wie man mit Greta ein SaaS-MVP ohne Code erstellt

TL;DR: Mit Greta können Sie in 7–10 Tagen ein SaaS-MVP ohne Code bauen. Das Playbook deckt Spec-Schreiben, Scaffolding, Datenmodell, Auth, das Kernfeature, Stripe-Zahlungen, Feinschliff und Launch ab --- alles aus Prompts in natürlicher Sprache. Gesamtkosten: unter 200 $ für den ersten Monat. Der Flaschenhals ist nicht mehr das Engineering; es ist die Klarheit der Nische, Disziplin beim v1-Umfang und die Distribution nach dem Launch. Dieser Leitfaden führt durch die exakte Prompt-Sequenz mit kopierfertigen Vorlagen.

Einführung

Ein SaaS-MVP ohne Code zu bauen bedeutete früher, 8–12 No-Code-Tools zusammenzustecken (Bubble für die App, Webflow für die Marketing-Site, Memberstack für Auth, Stripe mit individueller Integration, Airtable für Daten, Zapier zum Verkleben) und zu hoffen, dass das Klebeband hält. 2026 ist der Workflow dramatisch einfacher. KI-App-Builder wie Greta erzeugen aus Prompts in natürlicher Sprache echtes, funktionierendes Full-Stack-SaaS --- Frontend, Backend, Datenbank, Auth, Zahlungen, Deployment, alles in einem Workspace.

Dieser Leitfaden ist das vollständige Playbook. Nicht "theoretisch könnten Sie ein SaaS bauen", sondern die konkrete 7–10-Tage-Sequenz mit den exakten Prompts und Entscheidungen, die ein Nicht-Entwickler-Gründer braucht, um bis nächste Woche eine funktionierende v1 auszuliefern. Der Build ist die fokussierte Arbeit; die schwierigeren Teile (Nischenwahl, Distribution, Retention) werden erwähnt, sind hier aber nicht der Fokus.

Warum ausgerechnet Greta für No-Code-SaaS-MVPs

Greta ist einer von mehreren modernen KI-App-Buildern, die aus Prompts Full-Stack-Output erzeugen. Die Gründe, warum Nicht-Entwickler-Gründer es speziell für SaaS-MVPs wählen:

• Gebündeltes Growth-Tooling --- Domain, grundlegendes SEO, Analytics und Content-Management liegen direkt neben dem App-Builder. Für Solo-Gründer verdichtet das 3–5 separate Tool-Setups zu einem Workflow.
• Planbare Abo-Preise --- Keine Token-Verbrauchsangst während intensiver Iteration. Die Hardening-Phase vor dem Launch läuft routinemäßig über 20–50 Prompts; Planbarkeit zählt hier.
• Flexibilität bei mehreren Backends --- Supabase, MongoDB oder AWS, je nach Projektbedarf. Die meisten No-Code-KI-Builder sperren Sie auf einen Stack fest.
• Echter Code-Export nach GitHub --- Engineers können den Codebestand später erweitern, wenn das Produkt über das hinauswächst, was KI-geführte Entwicklung sauber bewältigt. Kein Vendor-Lock-in.
• Einheitlicher Workspace --- Spec, Build, Deploy, Blog und Analytics alle in einem Tool. Kontextwechsel sind die größte Ursache für ins Stocken geratene Solo-Builds.

Vor dem Build: die einseitige Spec schreiben

Das mit Abstand wirkungsvollste, was ein Nicht-Entwickler tun kann, ist eine straffe Produkt-Spec zu schreiben, bevor Greta überhaupt geöffnet wird. Builder, die das überspringen, brauchen routinemäßig 2–3× länger für die Iteration, weil die KI nicht weiß, was sie eigentlich wollen.

Eine gute Spec für ein erstes SaaS-MVP passt auf eine Seite und deckt acht Dinge ab.

• Zielnutzer --- Ein spezifischer Nutzertyp, nicht "jeder" (z. B. "freiberufliche Grafikdesigner:innen", nicht "Kreative")
• Problem --- Welchen konkreten Schmerzpunkt lösen Sie?
• Kernfeature --- Die eine wichtigste Aktion, die der Nutzer ausführt
• Datenmodell --- Welche Datensätze speichert die App? Listen Sie jede Tabelle mit Feldern und Typen auf
• Screens --- Welche Seiten gibt es, und in welcher Reihenfolge bewegt sich der Nutzer durch sie?
• Design-Vibe --- Referenzmarke oder -stil (z. B. "minimalistisch wie Linear"), Farbpalette, Typografie
• Integrationen --- Auth, Zahlungen, KI-Features, alles Externe
• Erfolgskriterien --- Woran erkennen Sie, dass v1 fertig ist?

Nehmen Sie sich 30 Minuten dafür. Öffnen Sie Greta nicht, bevor die Spec geschrieben ist. Das spart später Stunden.

Die 7–10-Tage-No-Code-Build-Sequenz

Hier ist die exakte Sequenz. Führen Sie die Prompts der Reihe nach aus; kombinieren Sie sie nicht; ein Feature nach dem anderen.

Tag 1: Spec und Scaffold

Schreiben Sie Ihre einseitige Spec (oben behandelt). Öffnen Sie Greta und fügen Sie die Spec als ersten Prompt ein. Fügen Sie noch nichts anderes hinzu.

Folge-Prompt: "Bau nur das Scaffold --- noch keine Features. Vier Screens mit Platzhalter-Inhalt: Landing, Dashboard, [Kernfeature-Seite], Einstellungen. Nutze Sidebar-Navigation auf Desktop, untere Tabs auf Mobile. Wende das Design-System aus der Spec an." Prüfen Sie, ob die visuelle Form stimmt, bevor Sie weitermachen.

Tag 2: Datenmodell und Beispieldaten

Führen Sie diesen Prompt aus: "Erstelle nur das Datenbankschema --- noch keine UI-Änderungen. Tabellen: User (id uuid, email text unique, name text, subscription_tier text default 'free', created_at). [Entity] (id uuid, user_id uuid foreign key, [feld1] type, [feld2] type, created_at). Füge Row-Level-Security hinzu, sodass jeder Nutzer nur seine eigenen Datensätze lesen/schreiben kann."

Dann Beispieldaten säen: "Befülle die Datenbank mit 5–8 Beispiel-[Entity]-Datensätzen, die einem Test-Nutzerkonto zugeordnet sind. Verwende realistische Feldwerte, kein Lorem Ipsum, damit die UI während der Entwicklung echt wirkt."

Tag 3: Authentifizierung

Fügen Sie Nutzerkonten hinzu. Führen Sie aus: "Füge Magic-Link-Authentifizierung per E-Mail hinzu. Bei der Registrierung einen User-Datensatz mit subscription_tier standardmäßig 'free' anlegen. Schütze /dashboard, /settings und alle darunterliegenden Routen. Nicht angemeldete Nutzer, die geschützte Routen aufrufen, sollen mit Rück-URL zu /sign-in umgeleitet werden."

Testen Sie den Auth-Flow selbst --- registrieren, anmelden, abmelden. Bestätigen Sie, dass geschützte Routen korrekt umleiten.

Tag 4–6: Kernfeature

Hier unterscheidet sich jedes SaaS. Das Muster ist gleich --- ein Feature pro Prompt, aufbauend auf dem Vorherigen.

• Tag 4: Eingabeformular --- "Bau das [Kernfeature]-Eingabeformular. Felder: [jedes Feld mit Typ und Validierung auflisten]. Beim Absenden in der [Entity]-Tabelle speichern und zur sichtbaren Liste hinzufügen. Erfolgs-Toast anzeigen."
• Tag 5: Listen- und Detailansichten --- "Bau die [Entity]-Listenansicht, sortiert nach [Feld] absteigend. Jede Zeile zeigt [Liste der Felder]. Klick auf eine Zeile öffnet die Detailansicht mit vollständigem Datensatzinhalt und Inline-Bearbeitung bei Fokusverlust."
• Tag 6: Suche und Filter --- "Füge Suche und Filterung zur [Entity]-Liste hinzu. Globale Textsuche über [durchsuchbare Felder auflisten]. Filter-Dropdowns für [filterbare Felder auflisten]. Filterstatus in URL-Parametern halten."

Tag 7: Stripe-Zahlungen

Sobald Auth und Kernfeatures funktionieren, Monetarisierung hinzufügen.

Führen Sie aus: "Integriere Stripe Subscriptions mit zwei Stufen --- Free (bis zu 3 [Aktionen] pro Monat) und Pro (19 $/Monat, unbegrenzt). Wenn ein Free-Nutzer auf Upgrade klickt, erstelle eine Stripe-Checkout-Session. Nach erfolgreicher Zahlung subscription_tier des Nutzers auf 'pro' setzen und Stripe-Kunden-ID sowie Abo-ID speichern. Auf Stripe-Webhooks hören: subscription.updated, deleted, invoice.payment_failed. Stufe entsprechend aktualisieren. Einen Stripe-Billing-Portal-Link in den Nutzereinstellungen bereitstellen."

Tag 8: Feinschliff

Feinschliff lässt die App fertig wirken. Drei Prompts erledigen das meiste davon:

• "Füge freundliche Empty States für jede Listenansicht hinzu --- Illustration, ein Satz Erklärung, CTA zum Anlegen des ersten Datensatzes."
• "Mach die ganze App vollständig responsiv auf Mobile. Tap-Ziele mindestens 44px. Modals werden zu Bottom-Sheets. Auf 375px-Viewport testen."
• "Füge Toast-Benachrichtigungen für alle Fehler mit freundlichen Meldungen hinzu. Rohen Fehlertext nie den Nutzern zeigen."

Tag 9: Audit vor dem Launch

Führen Sie den Sicherheits-Audit-Prompt aus: "Audit vor dem Launch. Bestätige (1) jede Datenbankabfrage ist über RLS auf den aktuell authentifizierten Nutzer beschränkt, (2) jede Nutzereingabe wird validiert, bevor sie gespeichert oder in Abfragen verwendet wird, (3) keine sensiblen Daten sind in URLs oder Client-Code sichtbar, (4) teure Operationen haben Rate-Limiting pro Nutzer, (5) Stripe läuft im Live-Modus und eine echte 1-$-Zahlung geht end-to-end durch. Markiere alles, was fehlschlägt."

Dieser eine Prompt fängt die meisten stillen Fehlerarten ab, die in Produktion auftauchen.

Tag 10: Launch

Verbinden Sie eine echte, individuelle Domain über Gretas gebündelten Domain-Workspace. Schalten Sie Stripe vom Test- in den Live-Modus. Führen Sie selbst eine echte 1-$-Transaktion aus, um zu verifizieren. Richten Sie einfaches Analytics mit Event-Tracking für Sign-up, First Action und Upgrade ein. Teilen Sie die URL mit 5–10 wohlgesinnten Nutzern für Feedback und beheben Sie die 2–3 wichtigsten Bugs, die sie finden.

Am Ende von Tag 10 haben Sie ein funktionierendes SaaS-MVP auf yourdomain.com, das echte Zahlungen entgegennimmt, mit Nutzern, die sich anmelden. Die Gesamtkosten liegen bei etwa 100–200 $ für Abos und unterstützende Tools --- verglichen mit 15.000–50.000 $ für dieselbe v1 über traditionelles Engineering.

Was in v1 rein soll vs. was übersprungen wird

Zu wissen, was man weglässt, ist wichtiger als zu wissen, was man baut. Diese Features sind in SaaS-Apps üblich und für v1 fast immer falsch.

In v1 einschließen

• Auth, das eine Kernfeature, Zahlungen, Dashboard, Einstellungen
• Mobile Responsiveness
• Empty States und grundlegende Fehlerbehandlung
• Magic-Link-Anmeldung per E-Mail (eine Auth-Methode reicht)
• Eine Abo-Stufe (Free + eine Pro)
• Transaktions-E-Mails für Onboarding und Billing-Events

Bis v2+ weglassen

• Mehrrollen-Berechtigungen und Team-Konten
• Mehrere Abo-Stufen (Free + Pro + Enterprise)
• Individuelle Integrationen mit Drittanbieter-Tools
• Erweiterte Analytics-Dashboards über Standard-Event-Tracking hinaus
• Social Login neben Magic-Link per E-Mail
• Mehrsprachigkeit
• Native Mobile-Apps (PWA über Web reicht für v1)
• Onboarding-Flows mit mehr als 3 Schritten

Jedes Feature, das Sie weglassen, ist ein Tag, den Sie sparen. Die meisten gescheiterten SaaS-MVPs scheitern, weil der v1-Umfang zu groß war, nicht weil der Build falsch war.

Was Bauen und Betreiben tatsächlich kostet

Realistische Kosten für einen Nicht-Entwickler, der ein erstes SaaS-MVP auf Greta ausliefert.

• Greta-Abo --- Abo mit gebündelter Kapazität
• Domain --- 12 $/Jahr (etwa 1 $/Monat)
• KI-API-Credits (falls Ihr SaaS KI-Features hat) --- 20–50 $ zum Start
• Transaktions-E-Mail --- 0–20 $/Monat (Resend, Postmark oder Loops-Free-Tarife decken die meisten Anfangsvolumina ab)
• Analytics --- Oft bei Greta gebündelt, oder sonst 0–10 $/Monat
• Stripe-Gebühren --- 2,9 % + 30 Cent pro Transaktion (nur bei Umsatz)

Gesamtkosten im ersten Monat: etwa 50–200 $, je nach KI-Nutzung. Verglichen mit dem Anheuern eines Entwicklers für dieselbe v1 --- typischerweise 15.000–50.000 $. Die Kostenkompression ist dramatisch.

Nach dem Launch: was als Nächstes kommt

Der Launch von v1 ist der Anfang, nicht das Ende. Die nächsten 30 Tage drehen sich typischerweise um fünf Dinge.

• Sprechen Sie persönlich mit Ihren ersten 5–10 Nutzern --- Ihr Feedback prägt den nächsten Monat der Arbeit mehr als Analytics es je könnten.
• Beheben Sie die 3 wichtigsten gemeldeten Bugs --- Versuchen Sie nicht, alles zu fixen; priorisieren Sie, was Conversion blockiert oder Churn verursacht.
• Feilen Sie am Landingpage-Text, basierend darauf, was frühe Nutzer tatsächlich gesagt haben --- Wortwahl zählt oft mehr als Features.
• Fügen Sie ein spezifisches Feature hinzu, um das frühe Nutzer konkret gebeten haben --- Nicht fünf Features; eine fokussierte Ergänzung.
• Richten Sie einfache Distribution ein --- Wählen Sie einen Kanal (X, LinkedIn, ein Nischen-Subreddit, Content-SEO) und gehen Sie im nächsten Monat tief hinein.

Fügen Sie nicht Features hinzu, nur um Features hinzuzufügen. Die Post-Launch-Phase dreht sich ums Lernen, nicht ums Bauen. Der Build ist der Anfang; Product-Market-Fit zu finden ist die eigentliche Arbeit.

Welche SaaS-Typen passen am besten zum No-Code-Greta-Workflow

Bestimmte SaaS-Typen passen besonders gut zum No-Code-Greta-Workflow.

• Vertikale CRMs und Pipeline-Tools --- Individuelle CRMs für spezifische Nischenbranchen (Recruiting-Agenturen, Hochzeitsfotografen, Versicherungsmakler). Gut verstandene Muster, hohe Zahlungsbereitschaft.
• KI-Tool-Wrapper --- Apps, die eine kostenpflichtige KI-API (Claude, GPT-4) in einen auf eine bestimmte Jobfunktion zugeschnittenen Workflow einbetten. Klarer Wert, einfache Struktur.
• Als SaaS verpackte interne Tools --- Apps, die als eigenes internes Tooling begannen und für andere in derselben Rolle neu verpackt wurden.
• Nischen-Produktivitäts-Apps --- Habit-Tracker, Zeiterfassung, Ziel-Tracker, zugeschnitten auf bestimmte Zielgruppen.
• Buchungs- und Terminplanungs-Apps --- Kalenderbasierte Tools mit Zahlungsintegration für bestimmte Servicekategorien.
• Nischen-Verzeichnisse und contentgetriebenes SaaS --- Kuratierte Verzeichnisse mit Premium-Einträgen, oder kostenlose Nutz-Tools, die Anmeldungen zu einem kostenpflichtigen SaaS treiben.

SaaS-Typen, die weniger gut passen: stark regulierte Systeme (HIPAA, PCI-geprüfte Finanzsysteme), Echtzeit-Multiplayer-Infrastruktur im großen Maßstab, performancekritische Systeme und Produkte mit neuartigen, algorithmuslastigen Kernen. Diese profitieren auch nach dem KI-Scaffold noch von traditioneller Engineering-Prüfung.

Häufige Fehler von Nicht-Programmierern beim Bauen von SaaS-MVPs

• Einen Mega-Prompt schreiben statt geschichteter Prompts --- Das häufigste Fehlermuster. Ein Feature pro Prompt, in Abhängigkeitsreihenfolge.
• Die einseitige Spec überspringen --- Anfänger, die das PRD überspringen, brauchen routinemäßig 2–3× länger für die Iteration.
• Zu breit bauen --- Ein SaaS "für alles" wird nie in 10 Tagen fertig. Wählen Sie einen spezifischen Nutzer mit einem spezifischen Problem.
• Zu niedrig bepreisen --- Bei 9 $/Monat Consumer-Pricing brauchen Sie Tausende Kunden für einen bedeutenden MRR. Bei 29 $+/Monat B2B-Pricing brauchen Sie 100–200. Wählen Sie bewusst.
• Zahlungen überspringen, weil "ich füge sie später hinzu" --- Von Woche eins an Geld zu verlangen, zeigt Ihnen, ob jemand wirklich will, was Sie bauen.
• Nicht auf einem echten Handy testen --- Mobile-Bugs sind der stille Killer. Immer auf einem echten Gerät testen.
• Nach dem Launch Features statt Kunden suchen --- Der Launch ist ~20 % der Arbeit. Die anderen 80 % sind Iteration, Retention und Distribution.
• Nach dem Launch auf zu vielen Distributionskanälen breit gehen --- Wählen Sie einen. Tief gehen schlägt breit streuen jedes Mal.

Häufig gestellte Fragen

F1: Kann ein kompletter Nicht-Programmierer wirklich in 7–10 Tagen ein SaaS-MVP bauen? Ja --- moderne KI-App-Builder wie Greta können in diesem Zeitrahmen ein funktionierendes SaaS-MVP aufbauen, wenn richtig geprompted wird. Der Flaschenhals ist nicht das Engineering; es ist die Klarheit der Nische, Disziplin beim v1-Umfang und Distribution nach dem Launch. Der Build ist mittlerweile der leichte Teil.

F2: Wie viel kostet Bauen und Launchen? Die Gesamtkosten im ersten Monat liegen typischerweise bei 50–200 $: Greta-Abo, optionale KI-API-Credits, Transaktions-E-Mail, Domain. Verglichen mit 15.000–50.000 $ für dieselbe v1 über traditionelles Engineering --- eine Kostenkompression von etwa 50–100×.

F3: Wird das SaaS produktionsreif sein? Für die üblichen 80 % der SaaS-Apps, ja --- Greta produziert Apps, die echte Kundenzahlungen entgegennehmen und echten Traffic bewältigen. Für die sicherheitssensiblen 20 % (regulierte Branchen, sensible Daten, Systeme mit hohem Traffic) ist eine einstündige Engineering-Prüfung vor dem Launch eine günstige Versicherung.

F4: Muss ich technische Fähigkeiten lernen? Etwas technisches Grundverständnis hilft --- zu verstehen, was eine Datenbank ist, was ein API-Call ist, was Authentifizierung bedeutet. Sie müssen keinen Code schreiben oder Syntax auswendig lernen, aber die Konzepte machen Ihre Prompts präziser.

F5: Was, wenn mein SaaS über das hinauswächst, was Greta bewältigen kann? Greta exportiert echten, funktionierenden Code nach GitHub. Gründer, die über die natürliche Skalengrenze der Plattform hinauswachsen, können Engineers hinzuziehen, um den bestehenden Codebestand zu erweitern, statt von vorn zu beginnen. Der Ausstiegsweg ist echt.

F6: Welche Preise sollte ich für mein SaaS-MVP festlegen? B2B-Pricing ab 29 $+/Monat ist die Schwelle, ab der die Rechnung für Solo-Gründer aufgeht. Bei 9 $/Monat Consumer-Pricing brauchen Sie Tausende Kunden für einen bedeutenden MRR. Bei 49 $/Monat brauchen Sie 100–200. Passen Sie die Preise an die Zahlungsbereitschaft Ihrer spezifischen Nische an; zielen Sie höher, als Ihr Bauchgefühl vorschlägt.

F7: Ist das wirklich 10× schneller als traditionelle Entwicklung? Ja, für standardmäßige SaaS-MVPs. Die Kompression ist strukturell --- KI übernimmt Boilerplate, gebündeltes Tooling verdichtet separate Setups zu einem Workspace, und der prompt-gesteuerte Workflow eliminiert Übergaben.

Fazit

• Ein SaaS-MVP ohne Code auf Greta in 7–10 Tagen zu bauen, ist für Nicht-Entwickler realistisch. Das Playbook ist strukturiert: Spec, Scaffold, Schema, Auth, Kernfeature, Zahlungen, Feinschliff, Launch.
• Der Build ist nicht mehr der Flaschenhals. Klarheit der Nische, Disziplin beim v1-Umfang und Distribution nach dem Launch sind die eigentlichen Beschränkungen.
• Die Gesamtkosten liegen bei 50–200 $ für den ersten Monat, verglichen mit 15.000–50.000 $ für traditionelle Engineering-Builds. Die Kostenkompression liegt bei etwa 50–100×.
• Der Launch ist ~20 % der Arbeit. Die 80 %, die folgen --- Kundengespräche, Iteration, Distribution --- entscheiden, ob aus dem MVP ein echtes Business wird.

Wählen Sie die SaaS-Idee, die Sie schon länger vor sich herschieben. Schreiben Sie dieses Wochenende die einseitige Spec. Öffnen Sie Montag Greta. Arbeiten Sie die obige 10-Tage-Sequenz durch. Bis nächste Woche haben Sie ein funktionierendes SaaS auf einer echten Domain, das echte Zahlungen entgegennimmt, mit echten Nutzern, die sich anmelden. Die Messlatte fürs Launchen hat sich verschoben. Das Einzige, was Ihren nächsten Launch aufhält, ist, welche Idee Sie heute Abend wählen.

---

Möchten Sie die Schritt-für-Schritt-Übersicht lesen? Lesen Sie: Ein SaaS-App mit KI von Grund auf bauen