led by Ryan Garver · Boise, Idaho Get Smart AI, led by Ryan Garver
Back to work

Design + build · 2026 · shipping

AI product-generation pipeline

One script that turns a short spec into a whole catalog of finished products.

50+ variants From one script
interior · cover · copy Per product
$0 Build cost
spec.yaml
├── interiors/   50+ print-ready PDFs
├── covers/      sized per trim + spine
├── copy/        titles, descriptions, keywords
└── manifest.csv one row per finished product
One spec in, a catalog out. Every artifact print-ready on the first pass.

Making digital products by hand, laying out interiors, designing covers, writing listings, does not scale. Each variant is another manual design pass. So instead of making products, I built the thing that makes them: you give it a short spec and it hands back a finished, print-ready product.

The problem: craft that does not compound

A one-off digital product is a day of layout work. Ten variants is ten days, and the eleventh is no faster than the first, because nothing you learned got captured. The goal was to move all of that effort once, into a generator, so that the marginal cost of the next variant drops to nearly zero.

The engine: one config in, a whole product out

A few parametric Python generators turn one config file into a complete product. Change a couple of values, like region, theme, or difficulty, and the same code produces a different finished SKU. One script covers 50+ variants, and I never touch the layout logic again. Each run produces the full stack, top to bottom:

  • Interiors. Multi-page, print-spec PDFs built in code, with front-matter and consistent typography.
  • Covers. Full-wrap cover PDFs computed to the exact spine width and bleed, so they upload as one file with no manual design step.
  • Listings. Formula-driven spreadsheets and ready-to-paste listing copy, generated alongside the assets.

The decisions that make it hold up

  • Deterministic by design. The same spec always produces the same files. The randomness in a puzzle is seeded, so a book is reproducible and auditable, not a lucky one-time render.
  • Computed, not placed. Covers and interiors are calculated rather than laid out by hand, so a 102-page book and its 0.230-inch spine line up every time, with no eyeballing and no reject from the printer.
  • Separated pieces. The content spec, the layout engine, and the output format do not depend on each other, so a new product line is a new config file instead of a rewrite.
  • Stdlib, straight to upload. Generation is dependency-light and produces the exact files a marketplace wants, so there is no print house, no pre-flight service, and no manual review loop after the generator runs.

How I verified it

The proof is the output: real print-ready PDFs, full-wrap covers sized to the computed spine, and formula-driven tracker spreadsheets whose dashboards recalculate as a user edits. The determinism is the test, run the same spec twice and you get the same artifact, which is what makes a catalog of 50 trustworthy rather than 50 things I have to inspect by hand.

This write-up is about the system, not the products. The storefronts it feeds are a separate venture I keep low-profile on purpose.

Why I point to this one

It is the clearest example of how I think about scale: not by working faster, but by moving the work up a level, into a system that makes the expensive thing cheap and repeatable. Parametric design, determinism, and separation of concerns are the same instincts that make an AI workflow scale instead of sprawl.