dev.to Article — READY TO POST

Platform: dev.to (https://dev.to/new)
Post window: Tuesday or Wednesday 8-10am PT
Estimated time to post: 15 min (paste, attach cover, set tags, set canonical URL if cross-posting)

EXACT TEXT TO PASTE

Title:

I Automated My Entire Digital Product Business on a $13/Month GCP VM. Here's the Architecture.

Tags: claudeai, ai, automation, productivity

Cover image: Use the satori cover at E:/Projects/claude-swarm-ops/_review/satori_sample_22.png (or 04 / 44, pick the highest-contrast one. No gradients.)

Body:

Three weeks ago I set up a loop on a $13/month GCP VM and went to sleep. By morning it had built, packaged, and queued Claude Code development guides for Gumroad. Autonomously. While respecting a set of rules I call OPERATOR.md.

This is the writeup: architecture, what worked, what surprised me, and the hard constraints that kept it from going sideways.

## The Problem

I had a pile of Claude Code config work I'd done across projects. Hooks, CLAUDE.md patterns, MCP server setups, workflow playbooks. Useful stuff that takes real hours to assemble. The kind of thing developers pay $20-40 for on Gumroad because assembling it yourself is tedious even if you know how.

The question: could I systematically convert that knowledge base into polished, verifiable products without hand-holding every step?

Answer turned out to be yes, with a catch. You have to design the autonomy carefully or the system either does too much (publishes before you review) or too little (asks permission for every file write).

## The Stack

**VM:** GCP e2-small, us-central1-a. 2 vCPU, 2GB RAM, 2GB swap. ~$13/mo on standard billing, free under trial credit. Enough for a Claude Code loop process plus subagents.

**Orchestration:** Claude Code CLI inside a `tmux` session. The operator is a Claude model that reads a constitution file, checks state, picks an action, executes, updates state, sleeps. No custom framework. Just Claude reading markdown and calling tools.

**Communication:** A bridge file at `~/.claude/bridge/inbox.md`. Human-in-the-loop responses land there. The operator tails it each tick and processes `GO`/`SKIP`/`EDIT` responses before deciding what to do.

**Storage:** Git-free. All state lives in `~/swarm/` markdown files. `STATUS.md` (live state), `LEDGER.md` (financial log), per-workstream `journal.md` files, and a `queue/` directory for pending human approvals.

## OPERATOR.md, The Constitution

Everything the operator does is governed by a constitution file it reads on every cold start. Key constraints:

markdown

Hard rules (NEVER without HITL)

• NEVER submit anything under Conor's identity to any external platform without human GO via bridge.
• NEVER spend money. Zero auto-charges.
• NEVER create accounts under Conor's name/SSN/email/card.
• NEVER push code to public repos under Conor's GitHub handle.
• NEVER execute real trades or move real money.

And what it CAN do without asking:

markdown

Auto-allowed (no HITL needed)

• Reading public data (web fetch, public APIs, marketplace browsing)
• Drafting content of any kind (must remain in ~/swarm/ until HITL approves)
• Researching opportunities
• Creating subagents
• Updating internal ~/swarm/ state

The pattern: build anything you want in the sandbox. Nothing leaves the VM without a human reading it first. This distinction between autonomous production and gated publication is what makes the whole thing tractable. The operator works at machine speed on the build side. Humans review at human speed on the publish side.

## The Loop

Each tick:

markdown

1. Read OPERATOR.md (the constitution)
2. Read STATUS.md (current state)
3. Read LEDGER.md (financial state)
4. Check inbox.md for HITL responses
5. Read workstream briefs
6. Check queue/ for pending items
7. Pick highest-EV action that fits the rules
8. Execute it
9. Update STATUS.md, LEDGER.md, journal.md
10. If artifact needs HITL: write to queue/ + send bridge message
11. Write next sleep duration to .next_sleep_seconds
12. Exit cleanly

Sleep defaults to 60 seconds. It writes longer (up to 3600) only when there's nothing to do except wait for an external event. A HITL response, DNS propagation, an API result. Otherwise: flat out.

## The Maker Workstream

The core build loop for digital products:

**Research subagent** reads HackerNews, Gumroad trending, relevant subreddits. Produces a decision doc with product idea, scope, target buyer, competitive angle.

**Build subagent** is given the decision doc and builds the full product directory:

- `CLAUDE.md` (the configuration file the product ships with)
- `hooks/` (6+ Claude Code hooks for the workflow)
- `patterns/` (recurring code patterns, annotated)
- `skills/` (reusable skill files)
- `examples/` (working examples per pattern)
- `README.md`, `QUICKSTART.md`, `VERIFICATION.md`
- `listing_draft.md` (Gumroad listing copy)
- `cover.png` (satori-generated, consistent visual style across the catalog)

**Verification:** the build subagent runs its own checklist before declaring complete. For a cookbook that means: can you `claude --dangerously-skip-permissions` on a blank project and have the hooks fire? Do the patterns reference real APIs? Are the examples actually runnable?

**Queue to HITL:** the listing draft gets queued to `~/swarm/queue/` with frontmatter (product, price, claimed value, link to draft). Bridge message goes out. My HITL surrogate (another Claude instance on a separate machine) reviews and responds GO/SKIP/EDIT.

**Publish:** after GO, a publish script creates the Gumroad product via API, uploads the zip, creates a launch discount code, adds tags, and attaches the listing copy. Gumroad caps product creation at ~10/day, which sets the publication cadence.

## What Surprised Me

**Subagent context isolation is a feature, not a bug.** Each build subagent starts fresh with only the task description. It can't drift from the operator's accumulated context. Clean handoffs via documented spec files beat "just remember what we discussed."

**State files beat memory.** Early in the design I thought about using Claude's memory system for tracking what's built. Bad idea. Files in `~/swarm/` are observable, debuggable, and survive process crashes. A flat `STATUS.md` that a cold Claude instance can read and immediately act on is worth more than any in-memory representation.

**The HITL gate is the interesting engineering problem.** Not "how do I automate everything" but "where exactly does autonomous output need a human eye before it touches the world?" For digital products: listing copy and the publish action need review, the build itself doesn't. For bug bounty: every finding needs review before submission. For freelance proposals: drafting is fine, the bid click is not.

**You hit the token budget before the idea budget.** Running under Anthropic's Max plan with a weekly cap. The real constraint isn't ideas or compute, it's tokens per subagent call. A build subagent that writes 30 files uses ~90K tokens. Five parallel subagents = 450K tokens. At that rate the weekly budget is meaningful. I track it in LEDGER.md and self-throttle at 80% of weekly allocation.

**Platform API limits matter more than I expected.** Gumroad caps product creation per day. That cap, not build speed, is the rate-limiting step for getting the catalog public. The build queue ran ahead of the publish queue almost immediately. The operator now drips one product per day until the queue is drained.

**No sales in 57 hours isn't a signal.** It's a baseline. Gumroad Discover doesn't activate until your first sale. The products aren't indexed yet. Distribution is the actual bottleneck, not product quality. Classic build-vs-distribution mistake running in real time.

## The Current Numbers

- 50+ products built across Python, Go, Rust, TypeScript, React, Next.js, Vue, Svelte, Angular, Flutter, Swift, Kotlin, Elixir, PHP, Rails, NestJS, GraphQL, Terraform, Django, Prisma, Bun/Hono, Supabase, Astro, Drizzle, Deno, Redis, tRPC, Cloudflare D1/R2, Zod, Vite/Vitest, TanStack Query, OpenAPI
- 13 live on Gumroad. The rest publish on a rolling daily cadence through end of June (Gumroad API cap, not a build constraint)
- All ship with satori-generated covers for consistent visual style
- $13/month VM cost, covered by GCP free trial
- ~$24 in Claude tokens across 56 operator ticks
- 0 sales. Distribution work begins now.

## The Distribution Architecture

Building 50+ products autonomously is a solved problem at this point. The open question is the first sale.

Distribution mirrors build: draft everything autonomously, queue for human review, human executes the identity-bound actions (posting, submitting, sending).

Current drafts in queue:

- Show HN post (done)
- Product Hunt launch pack (done)
- This dev.to article
- X thread (next)
- LinkedIn post
- Reddit r/ClaudeAI submission
- Dev-influencer DMs
- Email digest

The operator writes the drafts. I review and post. The bottleneck shifts from "can we produce content" to "does Conor have 20 minutes to review a batch and hit publish."

## What I'd Do Differently

**Start distribution earlier.** Right moment to draft Show HN was when product #1 shipped, not after the whole pipeline filled up.

**Account for platform API limits in the build spec.** I built 50+ products in three days. Gumroad lets me publish ~10/day. The build-vs-publish mismatch was avoidable if I'd checked the cap before scaling the build side.

**Smaller initial catalog, faster first sale.** 50+ products is a lot of pre-work before the market has spoken. A tighter V1, 5 products fully polished with covers and strong distribution, would have hit first sale faster. Catalog could have grown from there.

## The Catalog

Full catalog: https://claude-code-toolkit.pages.dev

13 cookbooks live right now. More publishing daily through end of June.

Use `LAUNCH40` for 40% off any product through launch week.

If you want to see the actual product structure before buying, the CLAUDE.md and `hooks/` files follow a consistent template I'm happy to share in the comments. The value is in the completeness and the integration patterns, not any single file.

Questions about the architecture? Ask in the comments. Happy to go deeper on the loop design, the HITL protocol, or the token budget management.