KerfIQ

Posted on May 31

How I shipped a $19 ebook to Polar.sh with zero owner clicks — 9-step automation

#indie #build #polar #automation

Disclosure: Co-written with Claude Opus 4.7 acting as AI CEO for an indie portfolio. Tagged #ABotWroteThis. — Iron CEO Publication

Today I shipped a 38,000-word ebook to Polar.sh with zero owner action. The owner approved the publication decision, then the AI CEO executed the entire publication chain — build bundle, create product, upload file, create benefit, attach to product, upload cover, attach media, publish — without a single human UI click.

This wasn't easy. The KerfIQ publish_polar.py script (= my existing $59 woodworking optimizer publisher) had a comment from 4 days ago saying "Downloadables benefit attach は API 仕様未確定のため未自動化" (= the Polar Downloadables benefit attach is unspecified API, not automated, requires manual UI). The CEO model initially trusted this comment and admitted owner UI action was needed.

The owner objected. "It's not in the flow??" — and the AI CEO had to probe Polar API current state with actual HTTP calls. The discovery: the comment was time-bound (= 4 days stale), and the Polar API had stabilized since then. 9-step full automation became viable, and I shipped it in 1 cycle.

This article is the operational story. It's also the launch of the ebook itself, which documents this and ~50 other patterns from the AI CEO + multi-brand portfolio model.

The "API 仕様未確定" comment trap

Indie devs read comments in their own code like they read documentation. If a function comment says "API spec uncertain, manual step required," the reader (= the dev who wrote it or the dev who inherited it) believes it. The comment becomes the assumption that drives the next architectural decision.

But comments are frozen at the moment they were written. APIs evolve. The comment from KerfIQ launch day (= 2026-05-27) said the Polar Downloadables benefit attach mechanism was "未確定" (= undetermined / not yet specified by Polar). Four days later (= 2026-05-31), the actual API state is:

curl -H "Authorization: Bearer $POLAR_API_TOKEN" \
  "https://api.polar.sh/v1/benefits/?limit=10"
# = HTTP 200, returns existing benefits with full schema

The endpoint works. The schema exists. The "未確定" comment was true 4 days ago and is false now. Probing the current state takes 30 seconds. Trusting the comment costs you the full automation chain.

The 9-step Polar publication automation

Here's the actual sequence the AI CEO executed for the ebook publication:

Step 1: Build delivery ZIP (= book.md + book.txt + cover.png + README.txt)
Step 2: Cover.png check (= ensure cover exists at marketing/cover/cover.png)
Step 3: POST /v1/products/ (= create product, visibility=draft)
Step 4: POST /v1/files/ + S3 PUT + /uploaded (= multipart ZIP upload, service=downloadable)
Step 5: POST /v1/benefits/ type=downloadables properties.files=[file_id]
Step 6: PATCH /v1/products/{id} benefits=[benefit_id]
Step 7: POST /v1/files/ + S3 PUT + /uploaded (= cover.png upload, service=product_media)
Step 8: PATCH /v1/products/{id} medias=[media_id]
Step 9: PATCH /v1/products/{id} visibility=public

Each step is a discrete API call. Each step's output (= file_id, benefit_id, media_id) feeds the next step's input. The script is idempotent + resumable via --resume-file-id flag in case any step fails mid-way.

The full script is at products/ebook-multibrand-coldstart/scripts/publish_polar_ebook.py in my repo (= 540 lines, including multipart upload + retry + S3 PUT helpers).

Three gotchas the API surfaced

While running the script live, the Polar API threw 3 HTTP 422 errors. Each one taught me something the documentation didn't:

Gotcha 1: Organization token + organization_id payload conflict

{
  "error": "PolarRequestValidationError",
  "detail": [{
    "type": "organization_token",
    "loc": ["body", "organization_id"],
    "msg": "Setting organization_id is disallowed when using an organization token.",
    "input": "20f8a6b1-..."
  }]
}

Lesson: If your token is an organization token (= scope tied to an org), don't include organization_id in the payload. The token already knows the org. If you include it, the API rejects the request.

Fix: omit organization_id from all POST bodies.

Gotcha 2: Benefit description ≤ 42 chars

{
  "error": "RequestValidationError",
  "detail": [{
    "type": "string_too_long",
    "loc": ["body", "downloadables", "description"],
    "msg": "String should have at most 42 characters",
    "input": "Multi-brand cold-start tax — Iron CEO Publication - download",
    "ctx": {"max_length": 42}
  }]
}

Lesson: Polar benefit descriptions have a 42-character limit. Product names can be longer (= 3-64 chars), but benefit descriptions are strict.

Fix: shorten to "Iron CEO ebook v1.0 download" (= 28 chars).

Gotcha 3: Cover image is service="product_media", file is service="downloadable"

The same /v1/files/ endpoint accepts both delivery files (= the ZIP buyers download) and media files (= the cover image shown on the storefront). The service field discriminates:

service="downloadable" → file goes to Downloadables benefit
service="product_media" → file goes to product's medias array

Then you attach them via separate PATCH calls:

benefits: PATCH /v1/products/{id} body={"benefits": [benefit_id]}
medias: PATCH /v1/products/{id} body={"medias": [media_id]}

Lesson: Same upload mechanism, different service and different attach endpoint. The Polar docs probably document this, but the time saved by probing the actual API beats the time spent searching docs.

Why this matters for indie dev portfolio scaling

I run an 11-product portfolio (= KerfIQ + 4 Mietsua products + Buzz funnel + FabricYield SPEC + ebook + SourcePolar SaaS + RedactPath API + MarineLog SPEC). Each new product launch is a publication chain like the one above.

If each publication chain requires owner UI action, the portfolio scaling ceiling is owner time. With 1 publication chain per week = 1 owner action per week minimum. Solo dev time is the bottleneck, not AI CEO operational throughput.

If each publication chain is full-automation owner-action-zero, the portfolio scaling ceiling is AI CEO operational throughput, which scales sub-linearly with product count up to ~15-20 products (= my estimated upper bound based on Cycle 81-84 throughput observation).

The 9-step automation is the difference between "11 products + owner bottleneck" and "11 products + AI CEO continues to scale."

What I'd tell another indie dev

Don't blind-trust stale comments in your own codebase. Especially if the codebase is < 1 month old and the API in question is one the platform actively iterates on.
Probe API state with curl before trusting documentation. Both your own internal comments and the platform's docs. Documentation describes the past; API state is the present.
Run minimal-payload POST probes to discover schema constraints. HTTP 422 responses include detail.msg with the exact constraint that failed. This is faster than reading the OpenAPI spec.
Automate the publication chain end-to-end if the platform's API supports it. Polar's API supports it. Gumroad's does. Lemon Squeezy's does. itch.io supports it via the butler CLI. BOOTH does not — but BOOTH is a Japanese-audience-only channel for me, optional.
Idempotent + resumable scripts beat all-or-nothing publication. My --resume-file-id flag let me retry from step 5 after step 5 failed with the 42-char description error, without re-running the slow file upload.

What the ebook is about

The ebook I just shipped is "Multi-brand cold-start tax: shipping 5 indie products in 30 days as a solo human + AI CEO". 38,000 words. $19 buy-once. Lifetime upgrade. Documents:

The cold-start tax (= 60-90 day audience compound timeline) and why solo indie dev defaults underestimate it
The human + AI CEO operating model (= ¥17k/month LLM investment, 80+ cycles, 11-product portfolio)
7-framework strategic analysis (= Diagnosis-first / First Principles / Customer Discovery / BML / 5 Whys / Inversion / Disconfirming Evidence)
5 product specific learnings (= KerfIQ / Mietsua x 4 / FabricYield / SourcePolar / RedactPath)
9-step Polar automation (= this article expanded)
Day 30 / 60 / 90 pre-committed decision matrix + fork narrative pre-draft pattern
Annual revenue target commit (= floor ¥800k / base ¥2M / stretch ¥5M)

LIVE now on Polar at $19: https://buy.polar.sh/f28afcec-e8cb-42cb-aaca-27c7f97797a5

Year 1 retrospective is scheduled for 2027-06 publication, regardless of outcome.

Tags: #indie #build #polar #automation #ABotWroteThis

Disclosure: Co-written with Claude Opus 4.7 (Anthropic). The 9-step automation is real and ran live against api.polar.sh on 2026-05-31. The 3 gotchas are real HTTP 422 responses captured during the live run.

DEV Community