This one comes directly out of operating a real apparel marketplace, the store that later became Zodega. Sellers hand you flat product shots: a shirt on a hanger, a dress laid out on a table. What actually sells the item is a lifestyle photo: a kid wearing the dress outdoors, in decent light, looking like a catalog. A real photo shoot for every SKU is out of the question for a marketplace moving fast, and one-at-a-time AI image editing is a fun demo that falls over the moment you have forty new products landing on a Tuesday. Product Pics is built for the Tuesday problem: it’s a batch tool, not an editor.
The workflow is shaped like catalog work actually is. Create a batch, choose a demographic (baby, boy, girl, man, or woman) and an age or age range like 5-8, then upload up to 100 product images at once. The app normalizes everything to PNG with Sharp, submits generation jobs to RunPod’s nano-banana-edit endpoint, and tracks them asynchronously while you go do something else. When the batch finishes, you download a zip with every generated image and a summary report. No interactive retouching, no canvas UI: generation, tracking, download. That narrowness is the product.
The garment is the ground truth
The hard constraint in apparel generation isn’t making a pretty image; image models do that for free now. It’s that the output has to stay faithful to the actual garment: the exact color, the texture, the print, the brand label. A seller will absolutely notice if the AI “improved” their product’s shade of blue, and a shopper who receives something that doesn’t match the photo is a return. That’s why this is built on an image-editing model rather than pure generation. The source product shot is the reference the model works from, and the prompt construction (demographic, age band, scene) shapes everything around the garment instead of reinventing it.
Variety across a batch is handled deliberately too. A hundred products all shot against the same AI-generated park bench looks worse than flat photos; it screams template. So backgrounds are assigned diversely across the batch from a curated set, which keeps a catalog page looking like it was shot over several real sessions instead of one prompt.
Boring infrastructure, chosen for batch scale
Uploads go directly to Cloudflare R2 via presigned URLs, so a hundred images never squeeze through the app server. It’s the same pattern I use in Agentbox, and for the same reason: serverless request bodies are the wrong place for file bytes. Job state lives in Postgres via Drizzle, RunPod jobs are tracked by polling, and failed generations get per-image retries so one bad job doesn’t poison a 100-image batch. Assets are treated as temporary by design, with an automatic cleanup model. This is a pipeline you run product through, not a photo library. Auth is better-auth with per-user batch history, and public signup is deliberately disabled; accounts get provisioned by hand because this is an operator tool, not a self-serve SaaS.
Product Pics was the standalone proof of a capability that later stopped being standalone: in Zodega, AI product imagery became native to the admin dashboard, generated against the live catalog. This is where that muscle got built, as a focused tool with exactly one job, sized for the actual volume a real store produces.