This is a build guide. By the end you’ll have a t-shirt store that designs products, lists them, takes payment, and ships them — with an AI agent doing the day-to-day and a human approving the things that should never be automated.
It’s not a thought experiment. The stack below is the one running shop.agenttree.army, which placed its first real order — Printful order 161851271, $17.31 charged through Stripe — about one day after the build started. That order is also what exposed the billing gotcha in Step 1: the customer’s charge went through, but production never did. It’s the reason that gotcha is called out so loudly below — this guide is written by someone who already paid for the lesson. The architecture write-up of that store lives in the case study. This page is the part the case study doesn’t cover: how you build one.
A store with no inventory and no warehouse. You design a shirt, a customer buys it, and a print-on-demand vendor prints and ships that single shirt. You never touch stock. An AI agent runs the loop — mining concepts, generating art, listing products, draining paid orders to fulfillment — and you approve designs and hold the money. That’s the whole shape of it.
The stack at a glance:
| Layer | Tool | Why it’s here |
|---|---|---|
| Fulfillment | Printful | Prints and ships per-order. No inventory, no minimums. |
| Payments | Stripe Checkout | Hosted checkout, handles cards + tax + PCI. |
| Storefront | Next.js on Vercel | Thin product catalog UI. Free tier is enough to start. |
| State | Supabase | Stores the catalog, variant maps, and order status. |
| Design | An image model (Ideogram) | Generates typographic tee art at ~$0.05/image. |
| Operator | An AI coding agent (Claude Code) wrapped in file-based state | Runs the agent suite on a cron heartbeat. |
The instinct is to reach for Shopify. Don’t — not for this.
Shopify is a hosted storefront with a monthly fee, a theme system, and an app marketplace. You’d be paying for a checkout and a CMS you don’t need, then bolting print-on-demand on as a plugin and fighting the abstraction every time the agent needs to do something the theme didn’t anticipate. The agent has to drive the store programmatically; a thin storefront you own is far easier to drive than a platform you rent.
Dropshipping is the other wrong turn. A dropship middleman sits between you and the supplier, marks up the unit cost, and gives you no control over print quality or fulfillment timing. Print-on-demand cuts the middleman: Printful is the supplier, and it exposes an API. You call it directly.
So the design is: print-on-demand vendor for the physical good, a thin storefront you own for the buying experience, and a payment processor that handles money and compliance. Three boundaries, each owned by the right specialist. The agent orchestrates across them.
This is the full path from empty repo to a store that can take a real order. The manual account setup is roughly 35 minutes; the rest is code the agent can write and you review.
Set up Printful (fulfillment)
Create a Printful account. Pick a base product — a unisex tee is the safest first choice — and note its product ID and the variant IDs for each size you’ll sell (S/M/L/XL/2XL each have their own variant ID). Generate an API token from the developer settings; you’ll store it as PRINTFUL_API_KEY.
Set up Stripe (payments)
Create a Stripe account and complete the identity/KYC steps yourself — this is a human-only step and stays that way (see the hard walls). Grab your secret key (STRIPE_SECRET_KEY) and set up a webhook endpoint pointing at your storefront’s /api/stripe-webhook route. Stripe gives you a signing secret (STRIPE_WEBHOOK_SECRET) — you’ll verify every incoming webhook against it so nobody can forge a “payment succeeded” event.
Use Stripe Checkout (the hosted page), not a custom card form. It handles PCI scope, 3-D Secure, and tax for you. Your storefront creates a Checkout session server-side with the line item and price, then redirects the customer to Stripe’s hosted page.
Stand up the storefront (Next.js on Vercel)
A new Next.js app. You need three things, no more:
/api/stripe-webhook) that verifies the Stripe signature and writes the order to Supabase.Deploy to Vercel. The free tier covers a low-traffic store comfortably.
Create the Supabase schema (catalog + order state)
Two tables carry the store:
merch_designs (or products): one row per approved design — title, image URL, Printful sync product ID, a variant_map of size → Printful variant ID, and a status (pending_review, approved, listed).merch_orders: one row per paid order — Stripe session ID, the resolved variant, customer shipping address, status (paid, submitted, shipped, failed), plus retry_count and last_error columns so a failed fulfillment is auditable and retryable rather than silently lost.Supabase is also where the agents read and write shared state, so they don’t need to talk to each other directly — the database is the message bus.
Wire the agent suite onto a heartbeat
This is the part that makes it “AI-operated.” The pattern is: an AI coding agent (Claude Code) wrapped in file-based state plus a suite of small, single-purpose agents, each fired on a cron heartbeat. No long-running brain holding everything in memory — each agent wakes up, reads its state from files and Supabase, does one job, writes the result back, and exits. State lives on disk; the schedule lives in cron.
The agent suite below lists each one. The two that need a tight cadence are the fulfillment drain (every ~2 minutes, so paid orders ship fast) and the design agent (daily is plenty). Everything else is event-driven (the order webhook) or low-frequency.
Install the hard walls — in code, not in a doc
Before you flip anything live, the three hard walls have to be real flags checked in the code path, not promises in a README. No real charge or reorder without an explicit live flag set to on. The agent has no credentials for any bank, Stripe-KYC, or domain-registrar account. Every design passes the IP gate before a single cent of image spend. Put these behind environment flags that default to off and require you to turn them on.
Go-live checklist
Walk this in order. Each line has burned someone.
Each agent does one thing and writes its result to shared state. None of them is large. The power is in the composition and the heartbeat, not in any single module.
Design agent
Daily. Trend-mines a handful of concepts from evergreen niches (dev humor, coffee, fitness, cats), runs every concept through the IP gate before spending on image generation, calls the image model to render the art, and stages a draft for your approval.
IP-safety gate
Fail-closed. A deterministic blocklist (brands, people, franchises, slogans) plus an LLM classifier that rejects on any doubt. If the model errors or can’t be parsed, the verdict is reject — never “safe.” This is what keeps you off the permanent-ban lists. How it works.
Catalog agent
Takes an approved design and lists it as a real Printful product, resolves the size variants, and persists the sync ID + variant map to Supabase. After this runs, the design appears as a buyable card on the storefront.
Order webhook
Event-driven. Receives the signed Stripe webhook on payment, verifies the signature, resolves the ordered variant, extracts the shipping address, and writes a paid row to the orders table.
Fulfillment drain
Every ~2 minutes. Picks up paid orders with no Printful confirmation, submits them to Printful as production orders, and records retry count and last error. Idempotent — a fixed bug just gets retried on the next tick, no manual re-queue.
Operator
The decide-brain on a sense → decide → act → review loop. Sets the mission, schedules the other agents, and is where the three hard walls are enforced so no automated decision can route around them.
A practical note on why typographic tees: an image model like Ideogram is text-forward, so designs where the typography is the product (terminal output, code humor, dry one-liners) play to its strength — and they sidestep the trademark minefield of logos and celebrity likeness art. That’s a deliberate product choice that happens to make the IP gate’s job easier, not a workaround for a weak model.
The honest version, because the asterisks matter. “AI-operated” does not mean “no human.” It means the human only touches the things that should never be automated.
The agent genuinely runs on its own: concept generation, IP screening, art generation, product listing, variant resolution, storefront display, checkout session creation, order ingestion, and fulfillment. Once a design is approved, nobody babysits the pipeline. A paid order finds its way to Printful without you in the loop.
Three things stay human-gated — enforced in code, not just intended:
Money
No real charge, payout, ad spend, or reorder happens without an explicit live flag turned on. The flags default to off. The agent can build the whole pipeline and run it dry; it cannot move real money until you say so.
Identity
The agent never holds credentials for a bank account, Stripe KYC, the domain registrar, or any identity-bearing account. These are yours, full stop. There is no flag that grants the agent access — the access simply doesn’t exist in its environment.
IP sign-off
Every design passes the fail-closed IP gate, and approved designs still need an explicit human “ship it” before they list. Uncertain is treated as no. The downside of a wrong “yes” (a banned store) dwarfs the downside of a wrong “no” (a wasted concept), so the threshold is deliberately strict.
If you want the store to be more autonomous over time, gate that on a track record: let a capability earn looser supervision only after a long run of clean decisions — and cap the hard-wall capabilities so they never graduate to full autonomy regardless of streak. Earned autonomy, with a ceiling on the things that can hurt you.
The reason this is buildable solo is that fixed costs are near zero — you pay mostly when you sell.
| Cost | Amount | Notes |
|---|---|---|
| Image generation | ~$0.05 per image | Only safe concepts (post-IP-gate) ever reach the model, so you don’t pay to generate art you can’t sell. |
| IP-gate LLM call | ~$0.001 per concept | Runs on a cheap model tier. The blocklist layer is free; the LLM layer is fractions of a cent. |
| Printful per unit | Variable (the production + shipping cost) | Billed to you per order — which is exactly why Printful needs a card on file. Set your retail price to cover this plus margin. |
| Stripe fees | ~2.9% + $0.30 per transaction | Standard processing. Build it into your price. |
| Vercel | Free tier | Adequate for a low-traffic storefront. Upgrade only if traffic demands it. |
| Supabase | Free tier | The free Postgres tier comfortably holds a catalog and order log at this scale. |
The unit economics are simple: retail price minus Printful’s per-unit cost minus Stripe’s cut is your margin. At a $30 shirt with a typical print-on-demand unit cost, that lands around a 50% margin — verify your own numbers against your chosen product and price before you trust the spreadsheet, because product and shipping costs vary by item and destination.
That’s the whole machine: a print-on-demand vendor for the physical good, a thin storefront you own, a payment processor for the money, an image model for the art, and an AI agent suite on a heartbeat to run the loop — with money, identity, and IP sign-off held back behind hard walls. The agent does the repetitive work. You supply the ideas and hold the things that matter.
The architecture write-up of the reference store — the one that placed Printful order 161851271 — is the case study. The IP gate and the three bugs the first sale exposed are each worth reading before you go live.