Eingereicht, geplant, live: warum jeder Status zählt

Jede Tabelle für Verzeichniseinreichungen fängt gleich an: eine Spalte namens „Status“, drei Werte – offen, erledigt, vielleicht noch „wartet“ – und eine Summe unten, die jedes Mal steigt, wenn jemand auf Absenden klickt. Zwei Wochen später sagt die Summe 40, die Zahl der Einträge, die ein Fremder tatsächlich finden kann, sagt 6, und niemand kann den Unterschied erklären, ohne jedes Konto erneut zu öffnen.

Der Unterschied kommt nicht von Faulheit. Er kommt daher, dass „erledigt“ fünf verschiedene Fragen auf einmal beantworten sollte. In diesem Artikel geht es um diese Fragen, darum, warum der Tracker von LaunchRepo jeder einen eigenen Status gibt, und um zwei Beispiele aus unserem eigenen seomap.dev-Lauf, bei denen ein einzelnes „erledigt“ falsch gewesen wäre.

Eine Spalte, fünf Fragen

Wenn du ein Produkt bei einem Verzeichnis einreichst, wollen die Leute, die sich für das Ergebnis interessieren, verschiedene Dinge wissen:

• Ist die Arbeit auf meiner Seite fertig? Habe ich alles ausgefüllt und den Knopf gedrückt?
• Hat die Plattform es bekommen? Eine Danke-Seite, eine E-Mail, ein Eintrag im Konto.
• Wartet es auf etwas? Moderation, einen Platz in der Warteschlange, eine Freigabe, ein Datum.
• Kann die Öffentlichkeit es sehen? Eine URL, die auch ohne Login lädt und kein „ausstehend“-Etikett trägt.
• Muss ich etwas tun? Ein CAPTCHA, eine Zwei-Faktor-Abfrage, ein Badge auf meiner Website, eine Entscheidung über einen kostenpflichtigen Weg.

„Erledigt“ beantwortet die erste Frage und behauptet stillschweigend die vierte. So wird aus einer Summe von 40 eine Summe von 6.

Die Status und die Frage, die jeder beantwortet

Der LaunchRepo-Tracker (record.py schreibt submissions.csv, dieselben Regeln gelten im lokalen Dashboard) nutzt elf Status. Jeder hängt an einer Mindestbeobachtung – an dem, was du tatsächlich gesehen haben musst, bevor du ihn einträgst. Gruppiert nach der Frage, die sie beantworten:

Arbeit auf deiner Seite

• draft – die Vorbereitung existiert, die finale Einreichung wurde nicht bestätigt. Ein gespeichertes Formular ist ein Entwurf.
• prepared_needs_human – etwas Konkretes blockiert die vorbereitete Arbeit, und nur ein Mensch kann es auflösen: CAPTCHA, 2FA, ein unklarer Kontostatus. Die Notiz sagt genau, was.

Die Plattform hat es erhalten

• submitted_pending_review – die Plattform hat den Eingang ausdrücklich bestätigt, die Moderation läuft noch.
• queued – die Plattform hat eine Warteschlangenposition oder einen Wartelistenstatus bestätigt. Anders als „in Prüfung“: Es gibt eine Schlange, und du stehst darin.
• scheduled – die Plattform hat ein Launch-Datum am oder nach deinem frühesten Launch-Datum bestätigt. Steht die Freigabe noch aus, gehört das in die Notiz; der Status bleibt scheduled.

Die Öffentlichkeit kann es sehen

• live – ein öffentlicher Eintrag wurde ohne „ausstehend“-Kennzeichnung verifiziert. Verlangt beim Erfassen die öffentliche URL und ein ausdrückliches Bestätigungs-Flag.
• already_listed – ein bestehender öffentlicher Eintrag wurde gefunden und verifiziert, bevor du überhaupt etwas eingereicht hast. Dieselbe Pflicht zu URL und Bestätigung.

Es ist gestoppt, aus einem Grund, den du benennen kannst

• blocked – Eignung, Kontokapazität oder ein Pflichtfakt, den du nicht hast.
• deferred_paid – der einzige nutzbare Weg kostet Geld; nichts wurde gekauft.
• not_a_fit – das Produkt erfüllt die Zielgruppen- oder Aufnahmekriterien des Verzeichnisses nicht.
• unavailable – der Weg oder die Plattform war nicht nutzbar; die Notiz hält fest, was beobachtet wurde.

Elf klingt nach viel. In der Praxis existiert jeder einzelne, weil sein Zusammenfallen mit dem Nachbarn mindestens einmal einen falschen Bericht erzeugt hat.

Beispiel 1: SaaSHub – öffentlich, aber in Prüfung

Die Einreichung bei SaaSHub, dokumentiert in der öffentlichen SaaSHub-Praxisanleitung, erzeugte eine Produktseite, die öffentlich erreichbar war. Jeder mit dem Link konnte sie öffnen. Sie trug außerdem ein sichtbares Etikett: Pending approval – Freigabe ausstehend.

Ein Ein-Spalten-Tracker trägt das als erledigt ein, vielleicht sogar als live – die Seite lädt ja. Die LaunchRepo-Regel sagt das Gegenteil: öffentliche Erreichbarkeit allein ist kein Beleg für Annahme. Der Eintrag bleibt submitted_pending_review, solange die Seite „ausstehend“ sagt, und wandert erst dann auf live, wenn jemand sie erneut öffnet, kein Etikett mehr sieht und die URL mit dem Bestätigungs-Flag erfasst. Im Fall SaaSHub hieß das: Der „live“-Zähler stieg am Einreichungstag nicht, und die Follow-up-Datei bekam ein Datum zum Nachfassen.

Das Detail, das die Anleitung ergänzt: Die Verifizierung der Domain-Inhaberschaft ist bei SaaSHub eine von der Anmeldung getrennte Anfrage. Das ist eine zweite Sache, die unabhängig ausstehen kann, und eine Notiz in der Zeile ist der richtige Ort dafür.

Beispiel 2: TinyLaunch – geplant, Freigabe ausstehend

TinyLaunch, dokumentiert in der TinyLaunch-Praxisanleitung, bot einen künftigen wöchentlichen Launch-Slot an. Der beobachtete Weg lief über einen Standard-Launch, einen Schritt mit optionalen Diensten, den man auf „keine“ setzen musste, eine Terminbestätigung und einen zweiten Upgrade-Dialog mit der Option „continue with free launch“, bevor die Erfolgsseite erschien. Das Dashboard zeigte danach das bestätigte Datum – und daneben Waiting for approval.

Zwei falsche Arten, das zu erfassen: live, weil ein Datum im Kalender steht; oder submitted_pending_review, weil die Freigabe aussteht. Der Tracker erfasst scheduled mit dem ausdrücklich übergebenen bestätigten Datum und hält die offene Freigabe in der Notiz. Beide Fakten überleben: Ein Datum existiert, und es kann sein, dass es nicht hält. Der Artikel zum Launch ohne Budget behandelt den Upsell-Teil desselben Ablaufs.

Hier zählt auch das früheste Launch-Datum. product.json trägt ein earliest_launch_date; der Tracker weigert sich, scheduled mit einem früheren Datum zu erfassen. Wer die Untergrenze auf „nach dem Livegang der Preisseite“ gesetzt hat, kann nicht versehentlich einen Launch für morgen einplanen, nur weil ein Verzeichnis den Slot angeboten hat.

Drei Regeln, die aus den Status folgen

Ein Danke-Bildschirm ist nicht live. Er ist bestenfalls submitted_pending_review. Die meisten Verzeichnisse, die manuell prüfen, brauchen Tage bis Wochen; mehrere kostenlose Stufen in unserem Lauf brauchten länger. Der Leitfaden zum Status-Tracking sagt ausdrücklich, dass eine lange Prüfschätzung weder eine Frist noch eine Garantie ist.

Eine Einreichung ist eine Zeile. Manche Verzeichnisse bieten ein Häkchen „auch an unsere Partnerseiten verteilen“ an. Es anzukreuzen erzeugt keine zweite Einreichung, bevor die zweite Plattform den Eingang selbst bestätigt hat. Der Tracker hält pro Plattform eine aktuelle Zeile und verlangt für eine Änderung ausdrückliches Ersetzen – ein Partner-Häkchen kann die Summe also nicht still aufblähen.

Übergaben an Menschen sind ein Status, kein Scheitern. Trifft ein Agent auf ein CAPTCHA oder eine Zwei-Faktor-Abfrage, trägt er prepared_needs_human mit der exakten nächsten Aktion ein und hält an. Das Dashboard führt diese Fälle unter „braucht dich“. Sie anders zu markieren – erneut versuchen, „wartet“, überspringen – umgeht entweder eine Plattformkontrolle oder verdeckt Arbeit, die du noch vor dir hast.

Warum ein Agent das dringender braucht als du

Wenn du bei fünf Verzeichnissen von Hand einreichst, weißt du noch, welches in Prüfung war und welches einen Kalender gezeigt hat. Ein KI-Agent, der eine Sitzung fährt, sie schließt und morgen neu gestartet wird – womöglich ein anderer Agent, auf einer anderen Maschine –, weiß das nicht. Er liest zuerst den Tracker und entscheidet aus dem Status heraus:

• prepared_needs_human und zur Prüfung fällige scheduled-Launches kommen zuerst.
• submitted_pending_review-Zeilen, deren Prüffenster abgelaufen ist, werden erneut geprüft – am bestehenden Eintrag, nicht mit einer neuen Einreichung, die die Schlange überspringt.
• live-Zeilen bleiben unangetastet.

Jede dieser Entscheidungen ist falsch, wenn der Status falsch ist. Hätten wir die SaaSHub-Seite als live erfasst, hätte nie jemand geprüft, ob sie freigegeben wurde. Hätten wir TinyLaunch als eingereicht erfasst, hätte nie jemand den Launch am bestätigten Datum verifiziert. Die Status sind das Gedächtnis des Agenten, und die Anleitung mit Claude Code zeigt, wie ein Lauf sie zu Beginn jeder Sitzung liest.

Wie ein guter Bericht aussieht

Statt „40 erledigt“ zeigt das Dashboard etwa: 6 live mit öffentlichen URLs, 21 in Prüfung mit Nachfassdaten, 4 geplant mit bestätigten Daten, 3 brauchen dich, 2 zurückgestellt, weil es keinen kostenlosen Weg gab, 4 nicht passend. Die Summe ist immer noch 40. Jede Zahl lässt sich verteidigen, und jede Gruppe hat eine offensichtliche nächste Aktion.

Mehr ist ein Tracker nicht. Er soll nicht beeindrucken – er soll der nächsten Person oder dem nächsten Agenten sagen, was wahr ist und was zu tun ist.

Wenn du deinen eigenen Lauf aufsetzt: So funktioniert es zeigt, wo der Tracker im Ablauf sitzt, die Seite für SaaS-Gründer beschreibt das Setup für ein Produkt mit echtem Launch-Kalender, und auf der Preisseite liegt die Einmallizenz für das Repository, in dem der Tracker mitkommt.

Quellen: RUNBOOK.md und AGENTS.md im LaunchRepo-Repository (Statustabelle und Mindestbeobachtungen), die öffentlichen Praxisanleitungen zu SaaSHub und TinyLaunch (beobachtet 2026-09-13) sowie der Leitfaden zum Status-Tracking. Die Berichtszahlen im letzten Abschnitt sind illustrativ, nicht gemessen.