SaaS mit Vibe Coding bauen: Prozess, Fallstricke und Checkliste

Freitagabend steht die Idee, Samstag läuft der Login, Sonntag nimmt der Stripe-Checkout die erste Testzahlung an. So fühlt sich Vibe Coding an, und dieses Tempo ist echt. Was in diesem Wochenende meistens fehlt, merkt man erst später: dass jede Tabelle über den öffentlichen API-Schlüssel lesbar ist, dass es keine Kopie der Datenbank gibt und dass niemand mehr weiß, warum das Abo-Modell so gebaut wurde, wie es gebaut ist.

Was Vibe Coding ist und welche Tools es gibt, steht in unserem Grundlagenartikel zu Vibe Coding. Hier geht es um die Praxis: wie man mit KI ein SaaS baut, das zahlende Kunden aus Deutschland, Österreich und der Schweiz verträgt. Ich baue selge.app und diese Seite mit Claude Code, und die wichtigste Lektion daraus steht ganz oben im Prozess.

Warum ich direkt in Claude Code starte

Der verbreitete Rat lautet, in Lovable oder Bolt einen Prototyp zu klicken und später zu einem Coding-Agenten wie Claude Code oder Cursor zu wechseln. Ich halte das für einen Umweg.

Wer in Claude Code startet, hat ab der ersten Minute ein echtes Git-Repository auf dem eigenen Rechner. Du entscheidest selbst über Framework, Hosting und Datenbankregion, also auch darüber, ob die Daten in Frankfurt liegen. Es gibt keinen Export, nach dem die Hälfte der Logik in einer Plattform zurückbleibt, und keinen Moment, in dem du ein Produkt verstehen musst, das ein anderes Tool für dich strukturiert hat.

Der Einwand, Claude Code sei nur etwas für Entwickler, trägt nicht weit. Claude Code läuft im Terminal, in VS Code und in der Desktop-App, und die Bedienung besteht aus Sätzen auf Deutsch. Was du lernen musst, sind ein paar Grundbegriffe: Repository, Commit, Umgebungsvariable, Datenbanktabelle. Das ist an einem Nachmittag erledigt und zahlt sich bei jedem Fehler aus, den du später selbst erkennst.

Lovable und Bolt haben ihren Platz, wenn du in einer Stunde einen Klick-Dummy für ein Kundengespräch brauchst, den du danach wegwirfst.

Phase 1: Planen, und zwar 80 Prozent der Zeit

Die wichtigste Lektion aus meinen Projekten betrifft die Verteilung der Zeit. Rund 80 Prozent gehören in die Planung. Wenn der Plan wirklich steht, ist das Bauen der kleinere und schnellere Teil. Wenn er wackelt, baut Claude mit voller Geschwindigkeit in die falsche Richtung, und jede Korrektur kostet mehr als die vorherige.

Die Plan-Datei

Alles beginnt mit einer Datei im Projektordner, zum Beispiel plan.md. Sie ist das Gedächtnis des Projekts, für dich und für Claude, das in jeder neuen Session bei null anfängt. Eine Struktur, die sich bewährt:

# Plan: [Produktname]

## Problem und Zielgruppe
Wer hat welches Problem? Wie lösen sie es heute?

## Kernabläufe (v1)
1. Nutzer registriert sich mit E-Mail
2. ...

## Bewusst NICHT in v1
- Team-Accounts
- Mobile App

## Datenmodell
Tabellen, Felder, wer darf was lesen und schreiben

## Stack
Framework, Datenbank (Region!), Hosting, Payment, Analytics

## Externe Dienste und DSGVO
Dienst | Zweck | AVV vorhanden | Serverstandort

## Offene Fragen
- ...

## Fortschritt
- [x] Login
- [ ] Checkout

Der Abschnitt "Bewusst NICHT in v1" ist der wertvollste. KI-Agenten bauen gerne mehr, als du verlangt hast, und eine schriftliche Grenze hilft beiden Seiten.

Gedanken diktieren statt tippen

Die beste Plan-Datei entsteht aus Rohmaterial, und das kommt schneller über Sprache als über die Tastatur. Ich diktiere meine Ideen, Einwände und halben Gedanken einfach hintereinander weg: wer das Produkt nutzt, was mich an bestehenden Lösungen nervt, was auf keinen Fall passieren darf. Zehn Minuten Reden liefern Claude mehr Kontext als ein sorgfältig formulierter Prompt, weil die Nebensätze mitkommen, die man beim Tippen weglässt.

Dafür eignet sich ein Diktier-Tool wie Wispr Flow, das in jedem Textfeld funktioniert, auch im Terminal. Wie das im Alltag aussieht, beschreiben wir in unserem Artikel zu Wispr Flow.

Claude dich ausfragen lassen

Der wirksamste Schritt in der Planung ist eine Umkehr der Rollen. Statt Claude Anweisungen zu geben, lässt du dich von Claude befragen. Schalte dazu den Plan-Modus ein (Shift+Tab oder /plan), in dem Claude lesen und vorschlagen, aber keine Dateien ändern kann. Ein Einstieg, der gut funktioniert:

Lies plan.md. Stell mir Fragen zu dem Produkt, eine nach der anderen,
bis du es gut genug verstehst, um einen Umsetzungsplan zu schreiben.
Frag besonders nach Dingen, die ich nicht bedacht habe: Randfälle,
Zugriffsrechte, was bei Fehlern passiert, Datenschutz.
Schlag mir zwischendurch Alternativen vor, auf die ich nicht
gekommen bin. Schreib noch keinen Code.

Claude stellt dabei richtig gute Fragen, oft genau die, an die man selbst nicht gedacht hat. Ein Teil davon ist unbequem. Was passiert mit den Daten, wenn ein Kunde kündigt? Darf ein eingeladener Nutzer die Rechnungen sehen? Was zeigt das Dashboard am ersten Tag, wenn noch keine Daten da sind? Jede Frage, die du nicht beantworten kannst, ist ein Hinweis, dass du noch nicht bauen solltest.

Der andere Teil macht dich kreativer. Claude fragt nach einer Zielgruppe, die du übersehen hast, nach einem Ablauf, der mit einem Schritt weniger auskommt, oder danach, ob das Produkt eine Aufgabe ganz ohne Eingabe des Nutzers erledigen könnte. Aus solchen Rückfragen entstehen in meinen Projekten regelmäßig Ideen, die besser sind als mein Ausgangsplan. Alles, was davon überzeugt, wandert in die Plan-Datei, der Rest in "Bewusst NICHT in v1".

Viele Designvarianten lokal erkunden

Hier liegt für mich der größte kreative Hebel beim Bauen mit KI. Eine Designvariante kostet heute fast nichts, also kannst du für jeden wichtigen Teil der App oder Website richtig viele davon durchspielen: 20, 30, auch 40 Versionen der Startseite, der Preisseite, des Onboarding-Schritts oder einer einzelnen Dashboard-Karte. Wer nur einen Entwurf sieht, bewertet ihn. Wer 40 sieht, entdeckt Lösungen, die er nie skizziert hätte, und erkennt die beste meist auf den ersten Blick.

So läuft das in Runden:

1. Breit starten. Lass Claude 20 bis 40 bewusst unterschiedliche Varianten eines Elements bauen, alle auf einer lokalen Seite untereinander, damit du sie im Browser durchscrollen kannst.
2. Favoriten wählen. Markiere drei bis fünf, die dich ansprechen, und notiere, was genau dir an jeder gefällt.
3. Kombinieren und vertiefen. Lass Claude aus den Favoriten neue Varianten bauen, etwa das Layout der einen mit der Typografie der anderen.
4. Festlegen. Die finale Lösung kommt mit Farben, Schriften und Abständen in die Plan-Datei, alle anderen Varianten fliegen raus.

Für ein Element dauert das ein bis zwei Stunden. Ein Redesign, nachdem 40 Komponenten auf dem ersten Entwurf aufbauen, dauert Tage.

Wann der Plan fertig ist

Der Plan steht, wenn du diese Punkte ohne Nachdenken beantworten kannst:

• Jeden Bildschirm der ersten Version in zwei Sätzen beschreiben
• Für jede Tabelle sagen, wer sie lesen und wer sie schreiben darf
• Alle externen Dienste nennen, mit Serverstandort und AVV-Status
• Den Umfang von v1 auf eine Seite schreiben
• Den Abschnitt "Offene Fragen" leer lassen

Erst dann geht es in die Umsetzung.

Phase 2: Das Fundament mit Leitplanken

Bevor die erste Funktion entsteht, legst du die Regeln fest, an die sich Claude in jeder Session hält. Dafür gibt es die Datei CLAUDE.md im Projektordner, die Claude Code bei jedem Start liest. Dort gehören Stack, Konventionen und vor allem Verbote hinein:

## Regeln
- Keine geheimen Schlüssel im Frontend-Code. Variablen mit NEXT_PUBLIC_
  sind im Browser sichtbar.
- Jede neue Supabase-Tabelle bekommt sofort Row Level Security und Policies.
- Niemals Befehle gegen die Produktionsdatenbank ausführen.
- Vor jeder Datenbankmigration fragen.
- Nach jedem funktionierenden Schritt: plan.md aktualisieren.

Wie man solche wiederkehrenden Anweisungen zu wiederverwendbaren Bausteinen macht, zeigt unser Artikel zu Claude Code Skills.

Drei weitere Entscheidungen gehören an den Anfang:

Git ab dem ersten Tag. Jeder funktionierende Zwischenstand wird committet. Wenn Claude etwas kaputt macht, gehst du einen Schritt zurück, statt eine Stunde zu reparieren.

Getrennte Umgebungen. Eine Datenbank für die Entwicklung, eine für die Produktion. Lokal liegen nur die Zugangsdaten der Entwicklungsdatenbank. Der Agent kann nicht löschen, wozu er keinen Zugang hat.

Ein Stack, der zu DACH passt. Ein typisches Setup: Next.js als Framework, Supabase als Datenbank mit Region Frankfurt, Stripe für Zahlungen über die irische Stripe-Gesellschaft und Plausible als cookiefreie Webanalyse von einem estnischen Anbieter mit Servern bei Hetzner. Die Region wählst du bei Supabase beim Anlegen des Projekts, deshalb gehört sie in den Plan und nicht in die Nacharbeit.

Phase 3: Bauen in kleinen Schritten

Wenn Plan und Leitplanken stehen, wird das Bauen fast unspektakulär. Der Rhythmus, der sich bewährt:

1. Eine Funktion aus der Plan-Datei auswählen, nicht drei
2. Claude zuerst den Umsetzungsweg beschreiben lassen, dann bauen lassen
3. Im Browser selbst durchklicken, auch die Fehlerfälle
4. Committen
5. Fortschritt in plan.md abhaken, neue Erkenntnisse ergänzen

Wenn Claude eine Änderung über 30 Dateien vorschlägt, ist der Schritt zu groß. Teile ihn auf. Für die kritischen Stellen, also Bezahlung, Zugriffsrechte und Datenlöschung, lässt du Claude automatische Tests schreiben. Bei diesen Abläufen reicht Durchklicken nicht.

Die Fallstricke, die echte Projekte getroffen haben

Die Risiken beim Vibe Coding sind gut dokumentiert. Drei Fälle zeigen, wo es konkret schiefgeht.

Offene Datenbanken

Im März 2025 entdeckte der Entwickler Matt Palmer, dass viele mit Lovable gebaute Apps ihre Supabase-Datenbank ungeschützt ins Netz stellten. Sein anschließender Scan fand 303 Endpunkte in 170 Projekten ohne wirksame Row Level Security. Die Lücke wurde als CVE-2025-48757 registriert. Lovable bestreitet die CVE mit dem Argument, dass jeder Kunde für den Schutz seiner Daten selbst verantwortlich ist.

Das Muster dahinter betrifft jedes Supabase-Projekt, egal mit welchem Tool gebaut. Der sogenannte anon-Schlüssel steht absichtlich im Frontend. Geschützt werden die Daten allein durch Row Level Security, also Regeln auf Datenbankebene, wer welche Zeile sehen darf. Laut Supabase-Dokumentation bekommen Tabellen, die über den Table Editor angelegt werden, RLS automatisch, per SQL angelegte Tabellen dagegen nicht. Und genau so legt ein Coding-Agent Tabellen meistens an.

Der zweite Schlüssel, der Service-Role-Key, umgeht alle Regeln. Er gehört ausschließlich in Server-Code und nie in eine Variable mit NEXT_PUBLIC_-Präfix.

Der Agent löscht die Produktion

Im Juli 2025 dokumentierte SaaStr-Gründer Jason Lemkin öffentlich ein mehrtägiges Vibe-Coding-Experiment mit Replit. Während eines ausdrücklich angeordneten Code-Freeze führte der Agent eigenmächtig Datenbankbefehle aus und löschte die Produktionsdatenbank mit Einträgen zu rund 1.200 Führungskräften und knapp 1.200 Unternehmen. Replit reagierte mit automatisch getrennten Entwicklungs- und Produktionsdatenbanken.

Die Lehre gilt für jedes Tool. Ein Agent mit Zugriff auf Produktionsdaten wird früher oder später etwas Falsches damit tun, egal wie klar die Anweisung war. Getrennte Umgebungen und regelmäßige Backups, die du mindestens einmal wiederhergestellt hast, gehören deshalb ins Projekt, bevor der erste echte Kunde kommt.

Unsicherer Code als Standard

Veracode testete 2025 über 100 Sprachmodelle mit 80 Programmieraufgaben. In 45 Prozent der Fälle enthielt der erzeugte Code Sicherheitslücken aus den OWASP Top 10, gegen Cross-Site-Scripting schützten die Modelle in 86 Prozent der relevanten Fälle nicht. Veracode verkauft selbst Sicherheitssoftware, die Zahl stammt aus einem eigenen Testdesign. Die Richtung deckt sich trotzdem mit der Praxis. KI schreibt Code, der funktioniert, und an Sicherheit denkt sie meist erst, wenn man ausdrücklich danach fragt.

Claude Code hat dafür einen eingebauten Befehl /security-review, der die offenen Änderungen auf Schwachstellen prüft. Vor jedem Launch und vor jeder größeren Erweiterung gehört er in den Ablauf, ergänzt um eine gezielte Frage: "Greif diese App an. Wie komme ich an Daten anderer Nutzer?"

Der Plan driftet

Der unauffälligste Fallstrick hat keine Schlagzeile. Nach drei Wochen weiß niemand mehr, warum eine Entscheidung so gefallen ist, Claude baut eine Funktion doppelt, weil es die erste Version nicht kennt, und der Umfang ist um ein Drittel gewachsen. Die Gegenmaßnahme ist banal und wird trotzdem ständig ausgelassen: die Plan-Datei nach jedem Schritt aktualisieren und neue Ideen in "Bewusst NICHT in v1" parken, statt sie sofort zu bauen.

DACH-Pflichten vor dem ersten zahlenden Kunden

Ein Coding-Agent baut dir eine Checkout-Seite, aber er weiß nicht, ob du sie in Deutschland so betreiben darfst. Diese Punkte musst du selbst klären:

Auftragsverarbeitungsverträge. Mit jedem Dienst, der personenbezogene Daten deiner Kunden verarbeitet, brauchst du einen AVV. Bei Supabase, Stripe und Vercel lässt er sich abschließen. Die Liste aus dem Plan-Abschnitt "Externe Dienste" ist die Grundlage für die Datenschutzerklärung.

Datenbank in der EU. Supabase bietet Frankfurt als Region an. Du legst sie beim Anlegen des Projekts fest, also prüf sie genau dort, statt sie später per Umzug zu korrigieren.

Keine echten Kundendaten in Claude. Claude Code sieht beim Bauen deinen Code, das ist unkritisch. Problematisch wird es, wenn du Produktionsdaten zur Fehlersuche in die Session kopierst. Pro und Max sind Verbrauchertarife, bei denen das Training per Opt-out abgeschaltet werden muss. Für Firmendaten sind Team oder Enterprise mit AVV gedacht, mehr dazu in unserem Artikel zu Claude Code im Mittelstand.

Impressum und Datenschutzerklärung. Das Impressum folgt seit Mai 2024 aus Paragraf 5 des Digitale-Dienste-Gesetzes (DDG), das das Telemediengesetz abgelöst hat. Unsere DSGVO-Checkliste für Online-Unternehmer geht die Punkte einzeln durch.

Abos an Verbraucher. Wer an Privatkunden verkauft, braucht einen Bestellbutton mit "zahlungspflichtig bestellen" oder gleichwertiger Formulierung (Paragraf 312j BGB) und einen gut sichtbaren Kündigungsbutton (Paragraf 312k BGB). Reine B2B-Produkte sind davon nicht betroffen, sollten das aber in den AGB klar regeln.

Umsatzsteuer. Seit 2025 gilt die Kleinunternehmerregelung bis 25.000 EUR Nettoumsatz im Vorjahr und 100.000 EUR im laufenden Jahr. Wer an Privatkunden in anderen EU-Ländern verkauft, muss ab 10.000 EUR Auslandsumsatz pro Jahr die Umsatzsteuer des Kundenlands abführen, in der Regel über das OSS-Verfahren. Stripe Tax kann die Berechnung übernehmen, die Meldung bleibt deine Aufgabe oder die deiner Steuerberatung.

Was es kostet

Die laufenden Kosten sind kleiner, als viele erwarten:

Ein kleines SaaS läuft damit für unter 100 EUR im Monat. Der Hobby-Tarif von Vercel ist laut Vercels Fair-Use-Richtlinien auf private, nicht-kommerzielle Nutzung beschränkt. Für ein Produkt mit zahlenden Kunden ist also von Anfang an Pro fällig.

Die Checkliste

Vor dem ersten Code

• plan.md angelegt mit Problem, Kernabläufen, "Bewusst NICHT in v1", Datenmodell und Stack
• Ideen diktiert und von Claude im Plan-Modus ausfragen lassen
• Für die wichtigsten Elemente viele Designvarianten lokal erkundet, finale Lösung festgehalten
• Für jede Tabelle definiert, wer lesen und schreiben darf
• Alle externen Dienste mit Serverstandort und AVV-Status gelistet
• Abschnitt "Offene Fragen" ist leer

Fundament

• CLAUDE.md mit Regeln zu Secrets, RLS und Produktionsdatenbank
• Git-Repository angelegt, Commit nach jedem funktionierenden Schritt
• Getrennte Datenbanken für Entwicklung und Produktion
• Supabase-Projekt in Region Frankfurt angelegt

Vor dem Launch

• RLS auf jeder Tabelle aktiv, mit zwei Testkonten gegengeprüft
• Kein Service-Role-Key und kein API-Secret in NEXT_PUBLIC_-Variablen
• /security-review gelaufen, gefundene Punkte behoben
• Tests für Bezahlung, Zugriffsrechte und Datenlöschung
• Backup einmal testweise wiederhergestellt
• AVV mit allen Dienstleistern abgeschlossen
• Impressum nach Paragraf 5 DDG und vollständige Datenschutzerklärung online
• Bei B2C: Bestellbutton und Kündigungsbutton umgesetzt
• Umsatzsteuer geklärt: Kleinunternehmer, Regelbesteuerung, OSS
• Hosting auf einem Tarif, der kommerzielle Nutzung erlaubt

Wenn du nur einen Punkt aus diesem Artikel mitnimmst, dann den ersten. Leg heute die plan.md an und lass dich zwanzig Minuten lang von Claude ausfragen, bevor eine Zeile Code entsteht. Die Fragen, auf die du keine Antwort hast, zeigen dir, wo dein Produkt noch nicht fertig gedacht ist.

Quellen

• Superblocks: Lovable Vulnerability Explained (CVE-2025-48757)
• Fortune: Replit-Agent löscht Produktionsdatenbank (23.07.2025)
• Veracode: 2025 GenAI Code Security Report (30.07.2025)
• Supabase: Row Level Security
• Vercel: Fair Use Guidelines
• IHK München: Kleinunternehmerregelung
• Claude: Preise und Tarife