Gumroad ist jetzt scriptbar. Hier ist der 12-Agenten-Stack, der meinen Store betreibt.

Drei Jahre. 22 Gumroad-Produkte gelauncht. Drei Nischen, tech und non-tech. Jeder Launch, dieselbe Rechnung: etwa eine Woche echte Arbeit pro Produkt, und das meiste davon ist nicht das Produkt selbst.

Diese Woche enthält die Idee. Das Positioning. Drei Cover-Iterationen, weil das erste immer billig aussieht. Zwei Überarbeitungen der Landing Page. Die Post-Purchase E-Mail-Sequenz. Das Analytics-Setup. Der Support-Thread der ersten Woche, wo fünf Käufer hintereinander fragen, ob der Download-Link funktioniert, obwohl der Download-Link immer funktioniert – sie haben ihn nur noch nicht ausprobiert. Bei jedem Launch sage ich mir, der nächste wird schneller. Er ist nie schneller. Derselbe Launch. Jedes Mal.

Gumroad hat das Spiel gerade neu definiert.

TLDR. Diese Woche hat Gumroad eine CLI ausgeliefert. Drei Schritte in meiner Kette wurden scriptbar. Neun andere wurden endlich wert, gescriptet zu werden. Ein Gumroad-Produkt hört auf, eine eingefrorene Datei zu sein und wird zu einem Service, der zuhört, patcht und sich selbst wieder rausschiebt. 12 Agenten, 5 Phasen. Kein Revenue-Multiplikator. Es wird exponentiell.

Die Gumroad API existiert seit Jahren. Jeder mit OAuth-Geduld und einem Server konnte bereits die Produkterstellung automatisieren. Niemand hat es gemacht. Die Setup-Kosten – App registrieren, Secrets speichern, Tokens refreshen, irgendwo eine Box am Leben halten – waren höher als die gesparte manuelle Zeit pro Launch. Die CLI ändert genau eine Sache. OAuth ist eingebaut, keine Keys zu speichern, Installation ist eine Zeile. Die Barriere fällt von "Dev-Projekt" auf "Nachmittag Klempnerei". Keine neue Fähigkeit. Eine neue Ökonomie.

Es War Nicht Unmöglich. Es War Unpraktisch.

Die Gumroad CLI ist keine schönere Oberfläche über der API. Die API war technisch offen. Praktisch war sie eine Festung: OAuth-App, Refresh-Token, eine Box die am Leben bleibt, und ein Wochenende Auth-Klempnerei bevor dein Agent jemals ein Produkt berührt. Die CLI kollabiert das zu drei Befehlen: install, gumroad auth login, export GUMROAD_ACCESS_TOKEN. Der zweite öffnet deinen Browser und handhabt OAuth nativ. Der dritte ist alles, was dein Agent braucht.

Non-interactive Mode ist ein Bürger erster Klasse (--no-input, --json, --quiet, --dry-run), und ein Claude Code Skill wird im Repo mitgeliefert, installierbar mit gumroad skill. Das Tool wurde für Agenten geschrieben. Menschen sind nur zufällig auch willkommen.

Ich habe vor ein paar Monaten argumentiert, dass CLIs MCP für Agent-Integration schlagen, weil die CLI-Oberfläche dort ist, wo Coding-Agenten bereits leben. Dass Gumroad eine CLI mit einem nativen Claude Code Skill im Repo ausliefert, ist etwa so saubere Platform-Level-Validierung, wie man sie bekommen kann.

Es war nicht unmöglich. Es war unpraktisch. Das ist ein echter Unterschied.

Drei der zwölf Items unten wurden erst diese Woche machbar. Die anderen neun waren vorher machbar, aber ihre ROI wurde negativ, sobald das Shipping manuell blieb. Schließ die letzte Lücke und die ganze Kette kippt von Hobby zu System.

\

Phase 1. Bevor Ich Ein Wort Schreibe.

Die meisten Gumroad-Verkäufer starten mit "welches Produkt soll ich machen". Der Agent startet mit "welches Signal sagt, dass etwas gewollt wird". Der Unterschied klingt klein. Er verändert, wohin die erste Stunde geht.

Item 1. Der Nischen-Signal-Miner. Der Agent kreuzt drei Quellen: deine eigenen Gumroad-Analytics (Produkte die konvertieren versus Produkte die flach lagen), Pinterest-Suchvorhersagen (echte Queries, keine Vermutungen), und Gumroad Discover Trending-Tags. Output sind drei Kandidaten-Winkel pro Woche, jeder mit Volume-Beweis. Ein Home-Workout-Programm-Winkel, der zweimal in zwei der Quellen auftaucht, ist ein echtes Signal. Ein "das fühlt sich cool an"-Winkel ist es nicht. Was früher einen halben Tag Tab-Hopping gekostet hat, dauert für den Agent etwa 15 Minuten, und er macht es nach Zeitplan, egal ob ich da bin oder nicht.

Item 2. Der Gap-Detektor. Der Agent liest öffentliche Reviews von direkten Konkurrenten, von Etsy-Äquivalenten, von Substack-Stores, die kürzlich zu Gumroad gewechselt sind. Er extrahiert, was Käufer explizit verlangen ("Ich wünschte, das hätte X") und worüber sie implizit klagen (dieselbe Frustration wiederholt in fünf Reviews, die niemand adressiert hat). Der Output ist eine priorisierte Liste unerfüllter Wünsche in deiner Nische. In zwei der drei Nischen, die ich betreibe, lag der Gewinner-Winkel meines letzten Produkts sechs Monate vor dem Launch in einem Konkurrenten-Review. Ich hatte ihn nur nicht gelesen. Der Agent liest sie alle.

Item 3. Der Cross-Nischen-Velocity-Tracker. Für Verkäufer, die in mehr als einer Nische arbeiten (ich, drei Nischen), trackt der Agent Conversion pro Nische über Zeit und sagt dir, wo du verdoppeln sollst, wo pausieren. Use-Case-sensitiv hier. Ich hätte fast eine meiner Non-Tech-Nischen nach sechs Wochen flachem Volume getötet. Stellte sich heraus, sie war saisonal. Wenn der Agent Berechtigung zum Killen gehabt hätte, hätte ich einen Kanal getötet, der vier Monate später die Miete bezahlt hat. Regel bleibt: Menschen entscheiden Kill, Agenten entscheiden Focus. Neunzig Tage Minimum an Daten, bevor eine Nische pensioniert wird.

Phase 2. Der Teil, Wo Ich Aufhöre, Eine Schreib-Sweatshop Zu Sein.

Die echten Kosten eines Gumroad-Launches sind nicht der Upload. Es sind die zehn Stunden Landing-Copy umschreiben, die vier Stunden Voice-Kalibrierung, die sechs Stunden A/B-Testing von Positioning-Winkeln. Hier verdient sich ein Agent sein Geld.

Item 4. Der Draft-Under-Contract-Generator. Ein Vertrag pro Nische, kein generischer Prompt. Ein Meal-Prep-PDF-Vertrag sagt "versprich nie Kalorienverluste, frame als wöchentliche Planungsstruktur only". Ein Fotografie-Preset-Vertrag sagt "spezifiziere immer die getesteten Kamera-Bodies und die Base-Exposure-Annahmen". Ein Writing-Craft-Workbook-Vertrag sagt "keine Produktivitäts-pro-Tag-Claims, frame als Übungsstruktur". Der Agent produziert einen ersten Draft unter diesem Vertrag. Früher habe ich v0.1 in vier Stunden geschrieben. Jetzt reviewe ich v0.8 in zwanzig Minuten. Ich bin das Pattern Ende-zu-Ende im Prompt Contracts Piece durchgegangen, und dieselben Mechaniken portieren ohne Modifikation zu Produkt-Copy.

Item 5. Das Self-Critique-Gate. Bevor der Draft mich jemals erreicht, kritisiert der Agent seinen eigenen Output gegen die Nischen-Rubrik. Verifizierbare Claims. Caveats vorhanden. Voice konsistent mit den letzten drei Launches. Er kommt mit einem Diff zurück, nicht mit einem Clean Slate. Der Haken: er approved immer noch über-optimistische Formulierungen etwa jeden fünften Draft. Ich habe einen Human-Veto-Schritt behalten. Keine Copy shipped ohne mein Read. Das habe ich bei einem manuellen Launch vor zwei Jahren gelernt, wo ich eine Landing Page mit "10x Produktivität"-Versprechen shipped habe und die nächsten zwei Wochen in den Reviews zerfetzt wurde. Gate deinen eigenen Draft. Dann gate das Gate.

Phase 3. Ein Befehl. Zwanzig Minuten. Das Ist Der Echte Job Der CLI.

Die CLI macht, was nur die CLI kann. Neun der zwölf Items in diesem Stack existierten in irgendeiner Form vorher. Diese zwei nicht, zumindest nicht ökonomisch.

Item 6. Das One-Shot-Ship-Script. Ein Claude Code Skill, der Gumroad CLI Calls zu einem einzigen Prompt verkettet. Du beschreibst das Produkt. Der Agent führt gumroad products create als Draft aus, uploaded die Datei (gumroad files upload), setzt Preis und Währung, hängt die Tags an, schreibt die Beschreibung in den Create-Call, führt gumroad products update aus, um das Cover anzuhängen, previewt den Output mit --dry-run, dann callt gumroad products publish, sobald du bestätigst.

Die Form des Shipping-Skills sieht ungefähr so aus:

gumroad products create \
  --name "Terminal Theme Pack v1" \
  --type digital \
  --price 12.00 \
  --tag "terminal" --tag "theme" --tag "dev-tools" \
  --description "$(cat landing.md)" \
  --custom-permalink "terminal-theme-v1" \
  --json --no-input

gumroad products update <id> --price 14.00 --dry-run --json --no-input

gumroad products publish <id> --json --no-input

\

Der vollständige Shipping-Run für ein neues Produkt war früher ~4 Stunden Click-Click-Click in der Gumroad Web UI. Jetzt sind es ~20 Minuten Ende-zu-Ende, und die menschliche Rolle schrumpft auf die Bestätigung von drei Entscheidungen: Preis, Cover, Go-Live. Harte Regel von Tag eins in den Skill geschrieben: jede Preisänderung erfordert einen Bestätigungsschritt, nie Auto-Execution. Ich habe zweimal in 22 manuellen Launches den falschen Preis gesetzt. Ein Agent wird es schneller und schlechter machen, wenn du diese Invariante nicht festpinnst. Der Bestätigungs-Prompt ist der Autosave vor einem Boss-Fight, und ich laufe diesen Dungeon nicht nochmal.

Item 7. Der Multi-Store-Router. Für Verkäufer, die separate Stores pro Brand führen (mache ich, einen pro Nische, für sauberes Positioning), liest der Agent die Tags des Produkts und routet zum korrekten Store-Token vor dem Shipping. Keine Cross-Brand-Kontamination. Es ist ein kleines Geländer, das die Art von 30-Minuten-Cleanup-Fehler verhindert, der mir früher einmal im Quartal passiert ist. Klein, aber die Art von Klein, die sich aufaddiert.

Phase 4. Wo Das Lebende Produkt Beginnt.

Ein Produkt lebt oder stirbt in den Reviews. Die meisten Verkäufer finden es heraus, wenn ein Refund reinkommt. Diese Phase verwandelt jeden Kauf in Input für den nächsten Zyklus, und es ist der Teil, der den Stack tatsächlich von einem klassischen Verkäufer entkoppelt.

Item 8. Der Post-Purchase-Trigger, J+7. Der Agent sendet eine E-Mail sieben Tage nach dem Kauf. Nicht einen Tag, sieben. Drei Fragen, nicht "wie war es?". Die drei, die ich über 22 Launches verfeinert habe: wofür hast du es tatsächlich verwendet (echter Use versus der, den ich angenommen habe), was hast du erwartet, was nicht da war (inverse Gap-Detection), würdest du für eine v2 zahlen, die X fixt (Pricing-Signal für den Patch-Zyklus). Die E-Mail ist pro Produkt und pro Käufer-Profil geschrieben (Erstkäufer versus Wiederholer). Das eine Non-Negotiable hier: nie triggern innerhalb des Refund-Fensters. Gumroads Refund-Fenster bei digitalen Produkten ist sieben Tage. Nach Feedback innerhalb dieses Fensters zu fragen hat bei einem manuellen Launch vor zwei Jahren meine Refund-Rate in einer Woche verdoppelt. Warte das Fenster ab. Dann frag.

Item 9. Der Sentiment- und Gap-Synthesizer. Feedback-Antworten gehen zuerst zum Agent, nie in meine Inbox. Er taggt jede Antwort (Feature-Request, Bug, Praise, Confusion), aggregiert wöchentlich pro Produkt und surfaced Patterns. Nicht "lies diese 200 E-Mails". Eher wie "43% erwähnen fehlendes X, 17% wollen Y, 8% beklagen sich über Z". Ein Fünf-Minuten-Read, kein 200-E-Mail-Slog. Der echte Value kickt eine Ebene höher: der Agent vergleicht Patterns über Produkte in derselben Nische. In einer Non-Tech-Nische, die ich betreibe, bekamen drei verschiedene Produkte still denselben Ask in ihren Reviews. Ich hätte es nie gemerkt beim Lesen Produkt für Produkt, weil jede Instanz eine Minderheit in ihrem eigenen Feedback war. Aggregiert über die Nische war es der #1 Ask. Das wurde das nächste Standalone-Produkt. Regel hier: der Agent verteilt Patterns, er rankt keine Prioritäten. Häufigkeit ist nicht Wichtigkeit. Eine Beschwerde von einem High-Value-Käufer kann drei casual Asks überwiegen. Die Verteilung geht an mich. Das Ranking bleibt menschlich.

Item 10. Das Refund-Post-Mortem. Jeder Refund triggert einen kleinen forensischen Pass. Der Agent pullt den Refund-Grund (falls der Käufer einen gegeben hat), cross-referenziert das ursprüngliche Purchase-Profil und taggt die wahrscheinliche Ursache: falscher Käufer, fehlendes Feature, Qualitätsproblem, Pricing-Mismatch. Wöchentlicher Report mit Totals und Root-Causes. Der Agent entfernt nicht den Bauchschlag einer 3-Uhr-morgens-Refund-Notification, die bekomme ich immer noch und zucke immer noch zusammen. Er gibt mir bis morgens eine Diagnose, statt mich bis Montag schmoren zu lassen. Das ist der echte Win.

Die meisten Verkäufer shippen und vergessen. Ein Agent hört weiter zu.

Phase 5. Der Loop Schließt Sich.

Zweiter Eintrag für die CLI, und der, der eine Launch-Pipeline zu einer Produkt-Schleife macht.

Item 11. Der V-Patch-Drafter. Der Agent liest die wöchentliche Feedback-Synthese aus Phase 4, identifiziert Requests, die in mehr als 20% der Antworten wiederkehren, und draftet die v1.1-Prioritätsliste. Ich approve oder rejecte jede Änderung. Für ein Fotografie-Preset-Bundle könnte v1.1 "drei weitere Warm-Tone-Varianten hinzufügen" sein. Für ein Fiction-Writing-Workbook könnte es "das Scene-Structure-Kapitel erweitern und den Typo in Übung 4 fixen" sein. Der Agent wendet die Änderungen auf die Source-Datei an, regeneriert Derivate (Cover-Tweak falls relevant, Preview-Pages), und dann, und das ist der Teil, der nur Post-CLI funktioniert, re-uploaded über die CLI. gumroad files upload plus gumroad products update pusht eine neue Version, und bestehende Käufer bekommen die updated Datei automatisch in ihrer Library. Über die Web UI gemacht, ist derselbe Patch zehn Minuten pro Produkt: Login, Produktseite, Edit-Files-Drawer, drag, warten auf Upload, save, verify. Über 22 Produkte auf einer monatlichen Patch-Kadenz sind das 220 Minuten Klempnerei jeden Monat, für eine Aufgabe, wo die echte Arbeit bereits getan war. Die CLI macht es zu dreißig Sekunden. Daran ist der Patch-Zyklus früher gestorben. Nicht Faulheit. Nur Mathe.

Item 12. Die kontextualisierte Update-E-Mail. Die finale E-Mail an bestehende Käufer ist nicht "neue Version verfügbar, hier downloaden". Sie ist pro Käufer, kontextualisiert. Wenn der Käufer Feedback mit Erwähnung von X geschrieben hat, öffnet die E-Mail mit einem Callback: "Du hast X in deinem Feedback geflaggt. v1.1 adressiert es direkt. Updated File ist in deiner Gumroad Library." Dieser Callback ändert die Beziehung. Der Käufer fühlt sich nicht wie ein Listen-Eintrag, er fühlt sich wie jemand, dessen Note gelesen wurde. Für Käufer, die nie geantwortet haben, bleibt die E-Mail neutral aber immer noch produktspezifisch, nie ein generischer Blast. Und ein hartes Cap, in den Skill geschrieben: eine Update-E-Mail pro Produkt pro Monat, Maximum. Ich habe vor zwei Jahren eine wöchentliche Kadenz bei einem Produkt getestet. Unsubscribe-Rate verdreifacht in drei Wochen. Käufer wollen keinen Newsletter. Sie wollen ein Produkt, das still besser wird in einem nachhaltigen Tempo.

Die Langweilige Wahrheit Über Scriptbare Stores.

Was sich tatsächlich ändert. Der Shipping-Schritt eines Launches geht von etwa vier Stunden auf etwa zwanzig Minuten. Feedback geht von "nie gesammelt" zu "wöchentlich synthetisiert". Der Patch-Zyklus geht von "nie" zu "monatlich". Kein Revenue-Multiplikator. Ein Zeit-Multiplikator, genau an den Stellen, wo Zeit in Klempnerei gefangen war.

Was sich nicht ändert. Das Produkt muss immer noch gut sein. Ein Agent rettet kein mittelmäßiges PDF, er beschleunigt nur die Geschwindigkeit, mit der du lernst, dass das PDF mittelmäßig ist. Die Nische muss immer noch echt sein. Das Positioning muss immer noch ehrlich sein. Ein Stack, der auf einem schlechten Produkt aufbaut, lehrt dich schnell, dass es ein schlechtes Produkt ist, was nützlich ist, aber es ist nicht magisch.

2025 hatte ein Gumroad-Verkäufer einen Store. 2026 haben sie einen Service, der läuft, zuhört und sich selbst umschreibt. Die CLI ist das kleinste Stück.

Der Loop drumherum ist das Produkt. Und er ist exponentiell.

Quellen

• Gumroad CLI, offizielles Repo und Install-Anweisungen: github.com/antiwork/gumroad-cli
• Gumroad Claude Code Skill (im Repo mitgeliefert): SKILL.md
• Sahil Lavingia über Gumroads AI-first Engineering-Kultur: Lenny's Newsletter Interview

Gedraftet mit Claude, editiert und shipped von mir.