Designed & built Case study In development

TrailPress Studio

A book production system that takes a title from concept to print-ready KDP interior. Thirteen pluggable content engines share one layout and export core — and it produced the books I've actually published.

Project
TrailPress Studio
Role
Creator & Developer
Timeline
2026

Designed & built

The problem it solves

I published a puzzle and activity book, and the process taught me where the real work is. It isn’t writing the content — it’s the production tail. Trim sizes and margin math that KDP will reject if they’re wrong, consistent typography across every page, front and back matter, page numbering, solution sections that have to match the puzzles exactly, and a print-ready PDF at the end.

Doing that once by hand is tedious. Doing it for a second book means doing all of it again. So I built the system instead.

The architecture

The core insight is that book types differ in their content generation but are nearly identical in their production requirements. A word search and a sudoku book need completely different generators — and the same trim geometry, page layout, footer handling, matter pages, and export pipeline.

So the system is a shared core plus a registry of interchangeable engines. Each engine implements a generator (produce the content) and a renderer (draw it on a page), then plugs into common assembly, layout, visuals and export.

Thirteen engines exist so far: word search, crossword, sudoku, maze, cryptogram, word scramble, fill-in-the-blank, trivia, would-you-rather, quote book, bucket list, journal, notebook, and coloring book.

The payoff is that adding a fourteenth book type means writing a generator and a renderer — not another book pipeline. The sudoku engine carries its own solver, symbol sets, themes and rules page, which is what a genuinely pluggable boundary lets you do: engine-specific depth without leaking into the core.

Where AI fits

The model handles idea generation and content drafting — seeding book concepts, generating word lists for a theme, producing trivia and prompts, patching a puzzle when a word won’t place.

It does not handle the puzzle construction. Grid generation, word placement, collision detection, sudoku solving and validation are deterministic algorithms, because a puzzle that’s subtly unsolvable is a returned book. The model is used for open-ended creative input where variety is the goal, and kept away from correctness-critical logic. That division is the same judgment call as Shimmer’s: generative where variation helps, deterministic where being right matters.

There’s also a custom dictionary and word validator, since generic word lists produce puzzles with words nobody recognizes.

Output

Print-ready interiors with configurable trim sizes, color schemes, page templates, visual treatments, front and back matter, and solution sections — plus a preview panel and page editor for reviewing before export. Documentation covers KDP’s specific formatting rules, which is where the constraint actually comes from.

Status

Working and in active use — it produced published books, including the Would You Rather title. It’s my own production tool rather than a commercial product, and the book data lives in the repository as JSON rather than a database, which is the right call for a single-operator tool and the wrong one for anything multi-user.

Questions about this work?

Happy to go deeper on any of it — the decisions, the trade-offs, or what I'd do differently.