A solo operator in front of a wall-mounted LG monitor split into a 3×2 grid of six Claude Code windows. A second identical grid runs on a vertical display beside it. One more window on the MacBook within arm's reach. Thirteen agents simultaneously building Shopify stores — each in its own context, each owning a layer of the build. Six to seven finished stores per day. $800 each. Less than $80/day in API spend. No team. No managers. No support. Just him, the monitor, and the token counter ticking in every header.
The whole operation is one person, one chair, three displays. The wall-mounted ultrawide carries the first 3×2 grid of Claude Code instances. A second display, rotated vertical, holds another 3×2 grid. The MacBook on the desk runs the thirteenth. Wires hanging out, monitor bolted to a stand, no office.
He's not on a flat-rate plan — he's on API billing, metered by tokens. The arithmetic is the entire business model: thirteen parallel agents pay for themselves on the very first client of the day, because every finished store sells for $800 and the thirteen windows together burn less than $80 across a full day of work.
Each window is a Claude Code session in its own working directory, with its own
CLAUDE.md, its own MCP connections, and its own scope of files
it's allowed to touch. They do not interfere with each other because they don't share a context window
— the orchestration happens through the filesystem, the Shopify Admin API, and the operator's eyes.
You are my new founder-engineer.
Most operators talk to Claude like an intern — "can you help me with...", "what do you think about...". He skipped that. The first window's system prompt is one line that immediately re-levels the relationship:
# /CLAUDE.md — Window 01 (Orchestrator) You are my new founder-engineer. You don't hint. You don't advise. You don't supplement. You own the result. The store ships, or it doesn't — and that is on you. # Working directory /projects/client-{{client_id}}/ # Authority - Read/write all files in this project. - Call the Shopify Admin API via the MCP server already configured. - Spawn sub-tasks in worktrees W02–W13 by writing briefs to /briefs/. - Mark a brief done by moving it to /briefs/_done/. # Definition of done A live, working store at https://{{slug}}.myshopify.com with: 80 products, payment + shipping live, 30 email flows armed, homepage + 50 banners shipped, GA4 + pixels firing, QA report green. No half-finished stores leave the floor.
That single framing — founder-engineer, not assistant — does more for output quality than any prompt-engineering trick. It tells the model what posture to take when something is ambiguous: decide, document, move on. Don't stop and ask.
Every agent gets one slice of the store and a tight, deliverable-shaped scope. The orchestrator (W01) is the only one that talks to the operator. Everyone else reads a brief, executes, writes files, and signs off. Below: the full roster.
section.liquid
templates or Shopify 2.0 JSON templates.
settings_data.json so the rest of the store inherits them.
Generates a one-page brand sheet for the client.
robots.txt.liquid.
Submits to Google Search Console.
New dropshipper drops a brief into the queue: niche, target country, supplier preference, a few reference stores. The operator pastes it into W01 (Orchestrator). That's the only manual typing of the day for this client.
~5 min · operator-driven
The orchestrator scaffolds the project directory and writes 12 briefs into
/briefs/, one per downstream window. Each brief contains:
the client niche, the brand voice, the deliverables, the file paths, and the deadline.
The operator opens each downstream window, types "read your brief and execute", and walks away. W02 (Catalog) and W05 (Brand System) run first because everything downstream depends on them. W03, W04, W06–W10 kick off as soon as their dependencies clear. W08 (Banners) waits on W02's product photos and W05's tokens.
~90 min · 11 agents in parallelOnce the homepage and PDPs are stable, W11 installs all pixels and wires the first A/B experiment. Runs late on purpose, because installing pixels before the layout settles produces noisy events.
~15 min · sequential after W04W13 is the bouncer. It places live test orders in three shipping zones, runs a full Lighthouse pass, walks every link, fires every email trigger. Green report → W01 packages the handoff. Red report → routed back to the responsible window with a fix list.
~20 min · W13 onlyW01 writes the delivery email — store URL, admin login transfer instructions, brand sheet attached, 30-day success checklist. Operator scans it, hits send. $800 invoice clears. Window 01 immediately starts pulling the next client from the queue.
~10 min · operator-confirmedSix finished stores a day, six days a week, fifty weeks a year, and the math is what the math is. The point isn't that anyone should chase that number — it's that the cost structure of building Shopify stores has been re-priced. A $3,500 build is now a $12 token spend wrapped in an $800 deliverable.
# Create the per-client template you'll clone for every new order. mkdir -p ~/factory/_template cd ~/factory/_template # Top-level layout mkdir -p briefs briefs/_done decisions assets/identity assets/banners \ catalog config sections templates qa # Per-window CLAUDE.md files — one per agent for n in $(seq -w 01 13); do mkdir -p windows/W$n touch windows/W$n/CLAUDE.md done # Shared MCP config mkdir -p .mcp touch .mcp/shopify.json .mcp/klaviyo.json .mcp/supplier.json
Every new client is cp -R _template client-{slug}. The factory
has a single source of truth for window prompts, file paths, and MCP wiring — touch it once,
propagate to all future stores.
Below are the three load-bearing prompts. Build the rest in the same shape — one role, tight scope, deliverable-shaped definition-of-done. (Full set of 13 lives in the template repo.)
You are my new founder-engineer. You don't hint. You don't advise. You own the result. # Working directory /factory/client-{{slug}}/ # Authority Read/write all files. Call Shopify Admin via MCP. # Your only job 1. Read /intake.md (the client brief). 2. Decide niche, brand voice, regions, payment, shipping. Write decisions to /decisions/01-foundation.md. 3. Generate 12 briefs in /briefs/W02..W13.md. Each brief contains: - GOAL (one sentence) - INPUTS (paths or URLs to read) - OUTPUTS (exact file paths the agent must produce) - DEFINITION OF DONE (the test that must pass) 4. Wait. When all 12 briefs are in /briefs/_done/, run the final QA review and write /delivery.md (client email + handoff). Never ask me a clarifying question. Make the call, log it, move.
You build the product catalog. 80 products. No more, no fewer. # Read /briefs/W02.md, /decisions/01-foundation.md # Tools MCP: supplier (CJ/AliExpress/Spocket), Shopify Admin # Write /catalog/products.json, then push to Shopify via API # Quality bar - 80 SKUs, deduped by image-hash + title-similarity. - Price = supplier_cost × markup_table[niche]. - Variants normalized (size XS–XXL, color names canonicalized). - Tags from the niche taxonomy in /decisions/01-foundation.md. - Every product must have ≥3 images and a non-empty body_html. Body_html is a placeholder — W03 (Copy Rewrite) will replace it. Done = 80 products visible in Shopify Admin AND /catalog/products.json snapshot committed.
You are the bouncer. No half-finished store ships. # Read /briefs/W13.md, all /briefs/_done/*.md # Tools MCP: Shopify Admin, headless browser (Playwright), Lighthouse # Run, in order 1. Test orders in 3 shipping zones (default + 2 international). Verify each completes through to confirmation page. 2. Walk every page (homepage, all collections, 5 random PDPs, cart, checkout, account, search, 404, policy pages) on desktop + mobile breakpoints. 3. Lighthouse on homepage + 1 PDP. Performance > 70 mobile. 4. Verify every email flow fires by triggering each event. 5. Validate JSON-LD schema, sitemap, robots, canonical tags. # Output /qa/report.md with: pass/fail per check, screenshots of failures, and — if any fail — a /qa/fixes-for-W{nn}.md addressed to the responsible window. Do not mark done if any check is red.
Use the official Shopify Dev MCP server or a custom one wrapping the Admin GraphQL API. W02, W03, W04, W06, W10, W11, W12, W13 all need it. Scope tokens by store — never one token across all clients.
CJ Dropshipping, Spocket, or AliExpress via a wrapper. W02 needs it. Cache the feed locally once per day — supplier APIs are rate-limited and slow, and you do not want every catalog agent re-pulling the same SKUs.
Custom server around Klaviyo's REST API. W07 needs it to push 30 lifecycle messages. Build this once, version-control the flow JSON templates per niche.
For W08 (banners) and W09 (logo), wire image generation (Higgsfield / Nano Banana 2 / Soul) and a background-removal service. W08's 50-banner pass is the single biggest non-Anthropic line item in the daily cost.
The reason store #200 ships as cleanly as store #1 is that every recurring decision has been promoted into a Skill. Skills are the durable knowledge layer — markdown files Claude Code loads automatically based on description match. Below: the minimum viable Skill set the factory runs.
settings_data.json structure. Without this Skill, W05 spends
tokens re-discovering what setting key controls which CSS variable.
--- name: shopify-product-loader description: Use when bulk-creating Shopify products via the Admin GraphQL API. Triggers on phrases like "load 80 products", "push catalog to Shopify", "bulk product create". Handles variants, images, tags, metafields, rate-limiting, and retries. Required for W02 (Catalog Builder). --- # When to use - W02 building a fresh catalog from supplier feed - Any agent that needs to write products to Shopify # Inputs you must have - A products.json with the canonical schema (see below) - A valid Shopify Admin API token in env var SHOPIFY_ADMIN_TOKEN # Steps 1. Validate products.json against schema in /skills/.../schema.json 2. Chunk products in batches of 25 for GraphQL `productSet` mutation 3. Call mutation; on rate-limit (429), exponential backoff 4. For each successful product, upload images via stagedUploads 5. Verify each product is visible in Admin (GET productByHandle) # Output - All 80 products live in store - /catalog/_loaded.json with Shopify product GIDs # Failure handling - If < 80 products land: write /catalog/_failed.json with reason per SKU - Never mark "done" with partial load. Hand back to W01.
The story is real-shaped, and the architecture is reproducible. A few caveats worth being honest about before anyone fires a credit card at the API.
Heavy banner generation, Opus on every window, long context windows, no prompt caching — and you can run $400/day on the same setup. The $80 number assumes ruthless model routing (cheap models for boilerplate, expensive only when needed) and aggressive caching.
At 6 stores/day, store #200 will look very similar to store #5 unless niches differ enough. Dropshippers paying $800 don't always notice; dropshippers building lasting brands will. The model only ships what the QA agent (W13) and the operator's eye let through.
Auto-built stores with auto-generated copy can ship trademark violations, regulated-product mistakes (supplements, cosmetics, electronics), or false claims. W13's QA needs a compliance check, especially if operating across regions with different ad/product law.
All 13 agents collapse if the supplier feed dies, the Shopify Admin API rate-limits, or Klaviyo throttles new accounts. Build queue + retry into every MCP server, and have a local cache so a 30-min outage doesn't kill the day's throughput.
$800 buys a great launch package, not a custom design system. The intake brief has to make that obvious. The operators who scale this without burnout sell "a working store, ready Monday", not "your forever brand."
"He decides 2 things" is the marketing line. The reality: the operator scans every QA report, fields edge-case escalations from W01, handles supplier outages, and answers client emails. Less than 5 hours of attention per day — but not zero.
Forget the $4,800/day headline. The architectural lesson is the one that travels: thirteen narrow agents, each owning one layer, coordinated through the filesystem, with one human deciding the gates — that pattern works for any production line where the deliverable can be decomposed into independent layers. Shopify stores today. Real estate listing sites tomorrow. SaaS landing pages the day after.
The "founder-engineer" framing isn't even Shopify-specific. You don't hint, you don't advise, you own the result is a posture-setting move that re-prices any agent's output, in any domain, by removing the assistant-shaped politeness tax from every turn. Try it once on a system prompt for any agent you currently call a "helper" — and watch what changes.