SaaS mit Claude Code launchen: Schritt für Schritt

Das ist die Anleitung, die ich mir vor meinem eigenen Launch gewünscht hätte: was tatsächlich passiert, in welcher Reihenfolge, wenn du Claude Code auf das LaunchRepo-Repository ansetzt und es bittest, dein Produkt in Verzeichnissen zu launchen. Sie folgt den Dokumenten des Repositories – START.md, ONBOARDING.md und BROWSER-SETUP.md –, aber in einfachen Worten und mit klar markierten Stellen, an denen du handeln musst. Nichts hier ist so spezifisch für Claude Code, dass es nicht auch mit Codex oder Cursor funktionieren würde; die Agenten-Seiten beschreiben die Unterschiede. Claude Code ist schlicht der Agent, den ich nutze.

Zwei Erwartungen vorweg. Erstens: Das ist kein Ein-Klick-Launch. Der Agent erledigt die repetitive Arbeit, aber du verbindest den Browser, gibst Texte frei, löst CAPTCHAs und bestätigst, was live ist. Zweitens: Kein Schritt unten verspricht einen Eintrag – jedes Verzeichnis entscheidet selbst, was es veröffentlicht, und viele kostenlose Stufen brauchen Wochen.

Schritt 0: Was du brauchst

• Das Repository. Nach dem Kauf bekommst du eine Einladung zu einem privaten GitHub-Repository. Klone es.
• Python 3.10 oder neuer auf macOS oder Linux. Tracker, Dashboard und Hilfsskripte sind reines Python ohne zu installierende Abhängigkeiten.
• Claude Code mit Browser-Integration. Ein Terminal allein kann keine Formulare ausfüllen; das Browser-Setup des Repositories nutzt Chrome DevTools MCP, das Node.js für npx braucht.
• Chrome 144 oder neuer, mit deinem Google-Konto und deinem Postfach angemeldet – dem, das die Verzeichnisse kennen sollen.
• Deine Produktfakten: Name, URL, eine echte Beschreibung, Preise, Launch-Phase, echte Screenshots und ein Logo. Keine Marketing-Wünsche; das, was heute existiert.

Schritt 1: Der Startprompt

Öffne den geklonten Ordner in Claude Code und füge den Prompt aus START.md ein, exakt so:

Read AGENTS.md, then follow “Start the dashboard for the owner”. Create my private workspace if I do not have one yet, start the dashboard, and give me the link.

Der Prompt ist auf Englisch und bleibt auf Englisch; der Agent spricht mit dir in deiner Sprache, sobald er die Anweisungen gelesen hat. Was dann passiert, ist deterministisch: Der Agent liest AGENTS.md, legt einen privaten Arbeitsbereich neben dem Checkout an – deine Produkte und Zugangsdaten liegen nie im Auslieferungs-Repository –, startet das lokale Dashboard und antwortet mit einem 127.0.0.1-Link. Öffne ihn. Alles Weitere lässt sich in diesem Tab oder im Chat erledigen; die Dashboard-Formulare schreiben dieselben Dateien, die der Agent liest.

Wenn du diesen Schritt lieber selbst machst: Das Repository dokumentiert zwei Befehle – einer initialisiert den Arbeitsbereich an einem Ziel deiner Wahl, der andere startet das Dashboard. Ein --demo-Flag liefert einen Wegwerf-Beispielarbeitsbereich mit einem fiktiven Produkt, falls du dich erst einmal umsehen willst.

Schritt 2: Das Onboarding-Interview

ONBOARDING.md weist den Agenten an, deine erste Sitzung Phase für Phase zu führen und vorhandene Dateien zu lesen, bevor er etwas zweimal fragt. In der Praxis fühlt es sich wie ein Interview an.

Wo wir stehen. Der Agent erklärt, was der Arbeitsbereich ist, und fragt nach Name, URL und dem lokalen Ordner mit Code oder Notizen deines ersten Produkts. Er sieht sich diese Quellen an, bevor er Rückfragen stellt, und stellt fest, welches Betriebssystem, welcher Agent und welche Browser-Werkzeuge er tatsächlich aufrufen kann – ihm ist ausdrücklich untersagt, Werkzeuge zu behaupten, die die aktuelle Sitzung nicht hat.

Ein privates Zuhause. Der Agent hilft dir, ein eigenes privates Remote für den Arbeitsbereich anzulegen, und erklärt unmissverständlich, dass dort gespeicherte wiederverwendbare Zugangsdaten für alle mit Zugriff auf dieses Repository lesbar sind – inklusive Historie. Du entscheidest, ob Zugangsdaten in den Arbeitsbereich, in einen Secret-Manager (nur Referenzen) oder nirgendwohin gehen. Die Arbeitsbereichsdatei hält diese Wahl fest.

Das Produkt. Ein Skript legt aus einem kurzen Slug einen Produktordner an; dann füllt der Agent product.json aus deinen Antworten: Zielgruppe, Problem, Unterscheidungsmerkmal, echte Funktionen, Preise oder Testphase, Launch-Phase, Screenshots und Logo. Ein Copy-Workshop macht daraus copy.md mit Varianten für verschiedene Feldgrenzen. Unbekanntes bleibt leer – der Agent darf weder Fähigkeiten von Wettbewerbern ableiten noch geplante Funktionen zu verfügbaren machen.

Diese Phase setzt auch das früheste Launch-Datum. Viele kostenlose Verzeichnisstufen stellen Einreichungen zur Prüfung in eine Warteschlange; die Bestätigung kann Wochen dauern. Der Agent fragt, ob es ein Datum gibt, vor dem nichts veröffentlicht werden darf, schreibt es in product.json, und der Tracker weigert sich, etwas vor diesem Datum als geplant zu markieren.

Identität. identity.json enthält den öffentlichen Namen, die E-Mail-Adresse, die Verzeichnisse nutzen sollen, deinen Nickname und die Organisationsfakten, die du veröffentlichen willst. Ein kurzes PR-Briefing folgt, in dem du korrigierst, wie der Agent dich beschreibt, bevor irgendetwas davon einen öffentlichen Eintrag erreicht.

Schritt 3: Chrome und Postfach verbinden

Das ist der Schritt, den Leute überspringen und sich dann wundern, warum der Agent sich nicht einloggen kann. Der Agent braucht einen Browser, den du sehen und beaufsichtigen kannst. BROWSER-SETUP.md bietet zwei Wege.

Weg A: dein bestehendes Chrome. Prüfe chrome://version (144+), öffne chrome://inspect/#remote-debugging in dem Chrome, das der Agent nutzen soll, und aktiviere dort Remote-Debugging. Dann trägst du Chrome DevTools MCP mit --autoConnect in die MCP-Konfiguration von Claude Code ein. Löse eine harmlose Browser-Aktion vom Agenten aus und bestätige Chromes Verbindungsanfrage selbst, im richtigen Fenster. Ein laufender MCP-Prozess ist kein Beweis für Browser-Zugriff; ein sichtbar bewegter Tab schon.

Weg B: ein dediziertes Profil. Starte Chrome mit eigenem User-Data-Verzeichnis im Arbeitsbereich und einem lokalen Remote-Debugging-Port, melde dich in diesem Fenster bei den nötigen Konten an und zeige die MCP-Konfiguration auf --browserUrl statt --autoConnect. Nie beides zugleich, nie mit einem über localhost hinaus erreichbaren Port.

Unter macOS gewährst du nur die Berechtigungen für Automation, Bedienungshilfen oder Bildschirmaufnahme, die deine Integration wirklich braucht; eine reine DevTools-Verbindung braucht meist keine davon. Chromes Verbindungsanfrage kann nach Reconnects erneut erscheinen – das ist eine Sicherheitskontrolle, kein Fehler, und das Repository weist den Agenten an, sie nicht wegzuversprechen.

Dann der Rauchtest: Der Agent öffnet einen frischen Tab, ruft die öffentliche Startseite eines Verzeichnisses auf, liest die Hauptüberschrift und sagt dir, welchen Tab er benutzt hat. Du siehst dasselbe Fenster. Als Nächstes meldet er sich bei einem Zielverzeichnis an und prüft das Kontomenü auf die richtige Identität – ein abgeschlossenes OAuth ist kein Beweis, auf der Zielseite eingeloggt zu sein. Zuletzt bestätigt er den Postfachzugriff, denn über Verifizierungsmails werden Kontoregistrierungen abgeschlossen. Manuelles Weiterleiten von Codes ist ein unterstützter Fallback; der Tracker hält es als menschliche Übergabe fest, nicht als automatisierten Zugriff.

Schritt 4: Berechtigungen, einmal pro Produkt

Bevor etwas eingereicht wird, liest der Agent WEBSITE-AND-EMAIL.md und stellt eine Handvoll Fragen, die er nicht erneut stellen wird: wo dein Website-Code liegt, wie er deployt wird, welcher Branch Produktion ist, ob er verlangte Verzeichnis-Badges in den Footer einbauen und pushen darf und ob kostenlose Registrierungen, kostenlose finale Einreichungen und die konkreten Aktionen mit Verifizierungsmails autorisiert sind. Antworten, Datum und exakter Umfang landen in authorizations.json. Ausgaben bleiben bei null – der Agent ist angewiesen, jedes bezahlte Upsell abzulehnen.

Die Badge-Frage zu verneinen ist in Ordnung; es schließt nur die Verzeichnisse aus, die eines verlangen. Was du nicht tun solltest: Berechtigungen eines Produkts auf ein anderes übertragen. Die Datei ist absichtlich pro Produkt.

Schritt 5: Das erste brauchbare Ergebnis

Jetzt lässt der Agent doctor.py laufen, das fehlendes Setup von abgelehnten Berechtigungen trennt, und wählt aus Playbook-Index und Katalog drei bis fünf Verzeichnisse, die zu deinem Produkt passen – er erklärt Passung und Voraussetzungen und beginnt mit einem zugänglichen kostenlosen Weg. Für jedes Verzeichnis treibt das Playbook dieselbe Schleife: zuerst nach einem bestehenden Eintrag suchen, prüfen, ob es die richtige Seite ist, Text innerhalb der Feldgrenzen vorbereiten, sicherstellen, dass nichts Geld kostet, nur innerhalb deiner Freigabe einreichen und das echte Ergebnis festhalten.

Rechne mit Übergaben. Ein CAPTCHA, eine Zwei-Faktor-Abfrage, ein unklarer Kontostatus oder ein verlangtes Badge stoppt den Lauf: Der Agent trägt prepared_needs_human ein, das Dashboard führt die Plattform unter „braucht dich“, und du erledigst diesen Schritt in deinem eigenen Browser. Das ist Absicht – das Repository verbietet Umgehung und Tarnänderungen.

Ein gutes erstes Ergebnis ist oft eine eingereichte Prüfung, keine Live-Seite. Das ist normal.

Schritt 6: Was die Tracker-Status bedeuten

Jedes Ergebnis läuft über record.py in submissions.csv, und das Dashboard zeigt dieselben elf Status. Jeder ist an eine Mindestbeobachtung gebunden, damit ein „erledigt“ nicht aufgeblasen werden kann. In meinen Worten:

• draft – die Arbeit ist vorbereitet, die finale Einreichung aber nicht bestätigt.
• prepared_needs_human – etwas Konkretes blockiert, und nur du kannst handeln: CAPTCHA, 2FA, ein unklares Konto.
• submitted_pending_review – die Plattform hat die Einreichung ausdrücklich erhalten, die Moderation steht noch aus.
• queued – die Plattform hat eine Warteschlangenposition oder einen Wartelistenstatus bestätigt.
• scheduled – die Plattform hat ein Launch-Datum am oder nach deinem frühesten Launch-Datum bestätigt; eine ausstehende Freigabe bleibt in der Notiz.
• live – ein öffentlicher Eintrag wurde ohne „ausstehend“-Kennzeichnung verifiziert. Braucht die öffentliche URL und deine Bestätigung.
• already_listed – ein bestehender öffentlicher Eintrag wurde gefunden und verifiziert; dieselbe URL- und Bestätigungspflicht wie bei live.
• blocked – Eignung, Kontokapazität oder ein fehlender Pflichtfakt verhindern Fortschritt.
• deferred_paid – der einzige nutzbare Weg kostet Geld; nichts wurde gekauft.
• not_a_fit – das Produkt erfüllt die Zielgruppen- oder Eintragskriterien nicht.
• unavailable – Weg oder Plattform sind derzeit nicht nutzbar; das beobachtete Problem ist notiert.

Drei Konsequenzen folgen. Ein Dankeschön-Bildschirm ist nicht live. Ein Partner-Verteilungs-Häkchen auf einer Seite zählt erst als zweite Einreichung, wenn die zweite Plattform bestätigt. Und scheduled auf einer kostenlosen Stufe kann trotzdem Wochen bis zur Veröffentlichung brauchen. Der Leitfaden zum Status-Tracking geht darauf ein, wie man das auseinanderhält.

Schritt 7: Einen fortsetzbaren Arbeitsbereich hinterlassen

Am Ende einer Sitzung aktualisiert der Agent die Onboarding-Checkliste nur für Dinge, die er tatsächlich beobachtet hat, schreibt unkritische Belege und offene Schritte nach SESSION.md, trägt die nächsten Termine in FOLLOW-UP.md ein und führt vor dem Push in dein privates Remote eine Git-Datenschutzprüfung durch. Die nächste Sitzung – deine oder die eines anderen Agenten – liest zuerst den Tracker, priorisiert Übergaben und zur Prüfung fällige geplante Launches, dann ausstehende Einreichungen, deren Prüffenster abgelaufen ist. Sie prüft bestehende Einträge erneut, statt noch einmal einzureichen, um in der Warteschlange vorzurücken.

Diese Fortsetzbarkeit ist der ganze Punkt. Dein zweites Produkt nutzt Browser-Setup, Identität, Freigabemuster und Playbooks wieder; nur product.json und die Texte sind neu.

Wie es weitergeht

Die Claude-Code-Seite hat denselben Startprompt, die Übergabeliste und die Browser-Hinweise auf einem Bildschirm. So funktioniert es zeigt die sechs Schritte mit dem Gründervideo. Im Verzeichniskatalog kannst du vor der Entscheidung ein paar öffentliche Playbooks lesen, und auf der Preisseite wird das Repository gekauft – einmal.

Quellen: START.md, ONBOARDING.md, BROWSER-SETUP.md und RUNBOOK.md im LaunchRepo-Repository (Release-Notizen im Changelog); der Startprompt ist wörtlich aus prompts/start.md zitiert. Zeit- oder Ergebniszahlen werden nicht genannt, weil keine über Kunden hinweg gemessen wurden.