Verzeichnis-Launch ohne Budget: ein Lauf ohne Ausgaben

Die meisten Artikel über Verzeichnis-Launches setzen ein Budget voraus: hier ein hervorgehobener Platz, dort ein „überspring die Warteschlange“, auf den Bewertungsseiten ein bezahlter Tarif. Dieser hier setzt das Gegenteil voraus. Die Regel für unseren eigenen seomap.dev-Lauf hieß null Ausgaben – nicht „günstig“, null – und die LaunchRepo-Playbooks erben diese Regel: Dem Agenten ist gesagt, nie Geld auszugeben, keine kartengebundenen Testphasen zu starten und keine bezahlten Upgrades anzunehmen. Was folgt, ist, wie ein Launch unter dieser Bedingung aussieht: langsamer, mit mehr Warten und mehr Übergaben – und mit einem Tracker, der ehrlich darüber bleibt.

Die Null-Ausgaben-Regel, genau formuliert

In AGENTS.md, den Anweisungen des Repositories an den Agenten, ist die Regel kurz: nie Geld ausgeben oder sachfremde Angebote annehmen; keine kartengebundenen Testphasen starten; keine bezahlten Upgrades annehmen. Sie steht neben den anderen harten Regeln – keine erfundenen Kundenzahlen, keine erzeugten Stimmen, kein Umgehen von Kontogrenzen –, weil sie dieselbe Art Regel ist: eine Grenze, die der Agent auch dann nicht überschreiten darf, wenn ein Formular das Überschreiten zum Weg des geringsten Widerstands macht.

Zwei Folgen. Jedes Verzeichnis, dessen einziger nutzbarer Weg Geld kostet, wird als deferred_paid erfasst – nichts gekauft, der Weg notiert, die Entscheidung bleibt bei dir. Und jedes Upsell, das innerhalb eines kostenlosen Ablaufs auftaucht, muss ausdrücklich abgelehnt werden, was mehr Arbeit ist, als es klingt.

Upsells abzulehnen ist ein Schritt, keine Nebensache

Kostenlose Wege sind selten ein einziger Knopf. In unserem Lauf führte der kostenlose Weg auf mehreren Plattformen über ein Angebot, eine Ablehnung, eine Bestätigung und ein zweites Angebot, bevor die Erfolgsseite kam. Die öffentlichen Praxisanleitungen dokumentieren, was wir gesehen haben:

• TinyLaunch: Der Standard-Launch bot optionale Dienste an, die auf „keine“ gesetzt werden mussten; nach der Terminvergabe erschien ein zweiter Upgrade-Dialog, und der kostenlose Weg ging nur über eine Option „continue with free launch“ weiter. Die TinyLaunch-Anleitung listet die Abfolge auf.
• SaaSHub: Der Einreichungsplan musste vor dem Absenden geprüft werden; die beobachtete kostenlose Option ist als Beobachtung dokumentiert, nicht als dauerhaftes Versprechen. Die SaaSHub-Anleitung behandelt das.
• PitchWall: Der verfügbare Plan wird vor dem URL-Import gezeigt; die PitchWall-Anleitung hält fest, ihn zusammen mit den Anforderungen zu Login-Zustimmung und Newsletter zu prüfen, bevor es weitergeht.

Der Leitfaden zur Planung ohne Ausgaben macht daraus eine Regel: prüfe jeden letzten Bildschirm. Kontrolliere die tatsächliche Summe, kontrolliere die finale Bestätigung und öffne gespeicherte Felder erneut, um zu sehen, ob sie erhalten geblieben sind. Ein übersprungener Warteschlangenplatz, den du nicht kaufen wolltest, ist trotzdem ein Kauf.

Keine Abkürzungen in der Warteschlange, keine Umgehungen

Null Budget verführt zu Dingen, die kostenlos, aber falsch sind. Die Playbooks verbieten sie alle, beim Namen:

• Einen Warteschlangen-Sprung kaufen – offensichtlich ausgeschlossen. Aber auch: erneut einreichen, um in der Schlange vorzurücken. Das Runbook weist den Agenten an, den bestehenden Eintrag erneut zu prüfen, statt noch einmal einzureichen.
• Ein zweites Konto anlegen, um eine Grenze zu umgehen. Uneeds beobachteter kostenloser Ablauf erlaubte einen ausstehenden Launch pro Konto und blockierte eine neue Einreichung, solange ein Produkt wartete. Die Uneed-Anleitung erfasst das als blocked mit nächster Aktion, nicht als Problem, um das man herumfährt.
• Ein anderes Produkt löschen, um einen Platz frei zu machen. Dieselbe Antwort.
• Eignung behaupten, die du nicht geprüft hast. Faziers beobachteter Basisweg verlangte Kommentare in der Community, ein sichtbares Badge und eine Domain-Bewertung über null in einem benannten Prüfwerkzeug. Ein Produkt, das das nicht erfüllt, hält an, bevor es die Erfüllung bestätigt – blocked, nicht „nah genug“. Die Fazier-Anleitung ist da deutlich.

Nichts davon ist Moralpredigt. Verzeichnisse, die Umgehungen bemerken, entfernen Einträge, und ein entfernter Eintrag nach Wochen des Wartens ist das teuerste Ergebnis, das ein kostenloser Lauf haben kann.

Bei den Übergaben geht die Zeit hin

Ein Lauf nur auf kostenlosen Wegen hat mehr Übergaben als ein bezahlter, denn die bezahlten Wege sind oft genau die, die eine Prüfung, ein Badge oder eine Verifizierung überspringen. Der Agent hält an und erfasst prepared_needs_human mit der exakten nächsten Aktion bei:

• CAPTCHAs und Zwei-Faktor-Abfragen. Nie umgangen, nie vom Agenten gelöst. Du erledigst sie in dem Browser, den du verbunden hast.
• Website-Badges. Mehrere kostenlose Stufen verlangen das Badge des Verzeichnisses auf deiner Seite. Das ist eine Änderung an der Website deines Produkts, braucht also deine festgehaltene Freigabe – einmal pro Produkt – und die offiziellen Badge-Dateien. Ablehnen ist in Ordnung; es schließt diese Verzeichnisse einfach aus.
• Verifizierungsmails. Registrierungen enden per E-Mail. Hat der Agent im verbundenen Browser Zugriff auf das Postfach, liest er den Code selbst; wenn nicht, leitest du ihn weiter, und der Tracker erfasst eine menschliche Übergabe statt automatisierten Zugriffs.
• Entscheidungen über kostenpflichtige Wege. deferred_paid-Zeilen warten auf dich. Manchmal lautet die Antwort „nein, überspringen“; manchmal ist ein Verzeichnis wichtig genug, dass du außerhalb des Laufs einmal zahlst und es selbst erfasst.

Das lokale Dashboard führt all das unter „braucht dich“. In einem Lauf ohne Budget ist diese Liste die eigentliche To-do-Liste; der Teil des Agenten ist meistens erledigt, wenn sie erscheint.

Prüfzeiten: Wochen, nicht Tage

Die größte Umstellung ist die Zeit. Kostenlose Stufen stellen in eine Warteschlange. Die Onboarding-Sitzung im Repository lässt den Agenten das vor der ersten Einreichung klar sagen: Viele Verzeichnisse mit kostenloser Stufe reihen Einreichungen zur Prüfung ein, und Bestätigung oder Veröffentlichung können nach dem Einreichen mehrere Wochen dauern, nicht Tage.

Konkrete Beobachtungen aus den Praxisanleitungen: PitchWalls abgeschlossene Einreichung blieb Under Review mit einer Schätzung von über 30 Tagen. TinyLaunch bestätigte einen wöchentlichen Slot, während die Freigabe noch ausstand. SaaSHub veröffentlichte eine Seite, die mit Pending approval gekennzeichnet blieb. Nichts davon ist eine Beschwerde – so sieht kostenlose Prüfung aus –, aber ein Tracker mit einer einzigen „erledigt“-Spalte hätte alle drei schon am ersten Tag als fertig gezählt.

Deshalb trägt product.json ein earliest_launch_date, und deshalb sagt das Runbook dem Agenten, keine Plattform-SLA zu erfinden: Nennt ein Verzeichnis keine Prüfzeit, vereinbarst du ein vernünftiges Nachfassdatum und prüfst dann. Der Artikel zu den Tracker-Status geht die genauen Status durch und erklärt, warum scheduled und „in Prüfung“ getrennt bleiben.

Was unser eigener Pilot zeigt

Der öffentliche Beleg für all das ist unser eigenes Produkt, seomap.dev, und er ist bewusst auf das begrenzt, was du nachprüfen kannst. Der aktuelle Lauf hat seomap.dev bei 160+ Verzeichnissen eingereicht; jedes davon ist entweder live oder wartet darauf, dass die Plattform veröffentlicht. Die öffentlich nachprüfbaren Einträge sind von der Über-uns-Seite verlinkt. Wir veröffentlichen keine Konto-URLs, keine E-Mail-Adressen und keine Screenshots von Postfächern, und wir veröffentlichen keine „live“-Zahl, die ausstehende Seiten mitzählt.

Sechs dieser Plattformen sind in öffentlichen Praxisanleitungen dokumentiert, und sie zeigen die ganze Bandbreite schon für sich: Product Hunt erreichte scheduled, SaaSHub blieb submitted_pending_review hinter einem „Pending approval“-Hinweis, TinyLaunch endete scheduled mit noch ausstehender Freigabe, PitchWall ging submitted_pending_review mit einer Schätzung von über 30 Tagen, Uneed kam blocked wegen einer Kontogrenze zurück und Fazier blocked wegen einer Eignungsregel. Diese Verteilung, nicht eine einzelne Zahl, ist das ehrliche Bild eines Laufs ohne Budget.

Versuche kalkulieren, wenn das Budget null ist

„Null Budget“ hat trotzdem Kosten: das Werkzeug, einmal, und die Nutzung deines Agenten, die dein Anbieter abrechnet. Der Leitfaden zur Planung ohne Ausgaben schlägt vor, die Kosten des Werkzeugs durch Produkte mal geplante Versuche zu teilen. Das Beispiel darin – 100 € auf vier Produkte mit je sechs Versuchen sind etwa 4,17 € pro Versuch, ohne Agentenkosten – ist Rechnen, keine Prognose. Passen nur drei Verzeichnisse zu deinem Produkt, verdoppelt sich die Zuteilung. Nichts davon sagt Annahme, Traffic oder Ranking voraus.

Was dir null Budget einbringt, ist eine saubere Antwort auf die Frage, die jedes Verzeichnis irgendwann stellt: „Hast du dafür bezahlt?“ Nein. Jeder Eintrag im Tracker ist über den kostenlosen Weg dorthin gekommen, innerhalb der Regeln der Plattform, mit einem Menschen, der überall dort eingesprungen ist, wo die Plattform einen wollte.

Selbst loslegen

Wenn du dieselbe Bedingung fahren willst: Die Indie-Hacker-Seite beschreibt das Ein-Personen-Setup, der Leitfaden zur Planung ohne Ausgaben ist die Checkliste, der der Agent folgt, und die Anleitung mit Claude Code zeigt eine vollständige Sitzung inklusive der Übergaben. Das Repository – 346 Playbooks, Produktvorlage, Tracker, Dashboard – wird einmal auf der Preisseite gekauft, und die Playbooks werden nie einen Kauf in deinem Namen autorisieren.

Quellen: AGENTS.md, ONBOARDING.md und RUNBOOK.md im LaunchRepo-Repository; die öffentlichen Praxisanleitungen zu TinyLaunch, SaaSHub, PitchWall, Uneed und Fazier (beobachtet 2026-09-13); der Leitfaden zur Planung ohne Ausgaben. Die Zahl 160+ ist der Einreichungsstand des Piloten zum Datum dieses Artikels; sie zählt Einreichungen, keine Live-Einträge.