A personalized children's book from a single questionnaire: from Telegram to the print shop with no illustrator, author or layout designer

Context

A personalized children's book in which the main character is your own child, looking exactly the way they look, is a gift parents want. Producing such a book the classic way takes an author, an illustrator and a layout designer: weeks of work and a unit cost incompatible with the retail price of a mass-market gift.

Generative AI is the obvious answer, but naive, head-on generation produces defects a parent spots in a second. The hero's hair changes color between pages. Grandma comes out the same height as her grandson. A winter scene — the child has no hat. In a boat, the benches run along the side.

An adult reader will forgive a weak plot. A child leafing through a book about themselves will not forgive turning into a different person on page five.

Meanwhile every redraw costs real money, and without strict control the spend runs away: on one early order the system burned through seventy-five images for sixteen pages — four times the plan.

And there's a separate wall at the end of the road — printing. Print shops accept only strict PDF/X-1a with exact geometry. An “almost right” file means a rejected order after the customer has already paid.

This is the product side of the story — how the book gets assembled. How this product is run by an autonomous system of agents is a separate case study.

Constraints

• One person and a self-employed budget. A server with one core and two gigabytes — generation and rendering parallelism had to be throttled artificially
• Economics on a knife edge. An image costs real rubles, and the payment channel's commission runs up to a third of the ticket. Every extra redraw eats directly into the margin
• Structured-output schemas don't forgive a single extra word. One unsupported keyword in the schema and the whole call fails with an error — and a paid order fails with it
• The image generator is unstable: it returns anywhere from 630 to 1024 pixels where print needs 1900 or more, and accepts at most three references per request
• Print has its own laws. PDF/X-1a is PDF 1.3: any transparency in the layout silently rasterizes the text. The trim size has to match to a tenth of a millimetre
• A print-shop API with half the rules undocumented: no price list, prices computed by a formula, order statuses bouncing between “rejected” and “uploaded”, order creation taking over a minute
• A rule written in a prompt is obeyed “sometimes”. On a long book the model loses the instruction: the hat went missing on three pages out of sixteen

Solution

What you get

A parent fills in a questionnaire in Telegram: the child's name, age, story theme and, optionally, a photo. Before paying, they see previews of the characters — so they know what they're buying. After payment they receive the finished PDF and, with a single tap, order a printed copy delivered to their door.

Between the questionnaire and the book there is not a single human.

How it works

The core is a generation pipeline with multi-level quality control.

One model writes the text. Then a separate “storyboarder” builds a specification for every page in a single pass over the whole tale: who is in frame, where they stand, what they hold, what they wear, what must not be drawn. One holistic pass instead of page-by-page is both cheaper and more coherent: continuity is reasoned over the entire book at once rather than stitched together from sixteen independent decisions.

On top of the model sit deterministic layers in plain code. A wardrobe by location and season: slippers at home, a helmet at the ice rink. A map of relative character heights by age. Shoe color alignment across pages.

Here lies the core principle of the whole project: a recurring defect gets fixed in code, not with a fourth paragraph in the prompt. Anything that must hold every single time cannot depend on the model's attention on page sixteen.

Next, every image goes through a visual check: a reviewer model compares the frame against the specification using a checklist of roughly fourteen categories — anatomy, scene physics, clothing, lighting. A final review looks at the book as a whole and catches what isn't visible page by page: “something changed between pages four and five”.

Spend is governed by a hard budget with separate named pools — mandatory frames, redraws, reserve. Every optional generation has to “ask for a ticket”. Plus pixel-level detectors that catch round vignettes and white margins, with a guaranteed rescue via cropping.

Layout is a separate module: HTML and CSS are rendered to PDF by a browser, with age-specific typographic systems (its own type size and color panels for ages 3–5, 6–8 and 9–12), embedded font subsets and text-overflow measurement right in the browser.

The print pipeline builds the print-shop files from the same sources: PDF/X-1a in CMYK, exact page geometry, bleed. Preflight runs on the rules of the specific print shop — a file their validator would reject never gets sent at all, and the owner sees the exact reason before submission.

Around the pipeline is a complete product loop: payment that survives restarts, automatic refunds, a personal account, sequels with the same characters, referral mechanics, an interface in twelve languages.

Architecture

One holistic storyboarding pass instead of N page-by-page ones: one extra call per book instead of sixteen, and coherence is reasoned over the whole thing at once.

Deterministic layers on top of the model — wardrobe, height, color. Critical rules are not entrusted to the LLM's attention.

An image budget in a context variable with separate pools and an emergency stop on any untracked spending path.

Fail-open for checks, fail-loud for generation. A reviewer failure doesn't bring the order down — the book simply ships without one check. A failure at a generation stage is an honest error with a refund, not silent degradation.

One layout, two targets. The on-screen PDF and the print block are built from the same sources, so the paper book is guaranteed to match the digital one.

Different models for different jobs: a fast one for dialogue, a strong one for the tale, a strong one for visual checks, a specialized generator for images. Caching the system prompts brings repeated reads down to roughly a tenth of the price.

Every real-world defect becomes an automated test. A log of every breakage that reached a customer, with order numbers in the names of the test blocks. That's why seven hundred checks aren't coverage for coverage's sake — they're a case history.

Stack

Outcome

A book that in classic production takes an author, an illustrator and a layout designer is assembled from a single questionnaire with no human involved.

Layouts pass the print shop's automatic validation and moderation — two print runs are in production. Before preflight existed, files were rejected after the customer had paid: the order exists, the money is gone, there will be no book.

Generation spend is held in check by a hard budget with named pools. Before it existed, a single order could burn four times the planned number of images — and eat the whole margin.

Seven hundred regression checks, each tied to a real defect that reached a user.

An interface in twelve languages — and the questionnaire works even when the model is unavailable.

What I'd do differently

• A silent fallback is evil. When the new engine failed, it quietly fell back to the old one. The customer got a book “made the wrong way”, and the only sign was one line in a log. Reworked into an honest error with a refund: better to admit a failure than to quietly deliver the wrong thing
• A big rewrite in one piece didn't fly. The second version of the continuity engine was built to a large spec, deployed — and deleted wholesale two days later; the quality wasn't there. Evolution in small, verifiable steps beats revolution
• A keyword detector without context is worse than nothing. Searching for the word “water” turned a pot of boiling water into a seascape, and a home-scene page drifted off to the beach. Stepped on that twice. Now only context-aware detectors with negations
• Data gets lost at serialization boundaries. Character ages were read from the database but never written to it — and the height rule silently vanished from the prompts. Hence Grandma the same height as her grandson. A field that isn't on the required list is a field the model won't return
• External systems' statuses can't be trusted from a single read. An order blinked to “rejected” and came back to “uploaded”. On a single read, the bot would have refunded a book the print shop went on to print. Now irreversible actions happen only after a confirming second read
• Print doesn't forgive “almost”. 154.18 mm instead of 154.0 — rejected. Bleed is required, but the size must be standard, and the answer turned out to be the correct geometry of the trim block. Transparency in CSS silently turns text into a bitmap
• Some timeouts have an empty text representation — the log was left with “print shop unavailable: ” and no reason. All external API errors are now logged with the full object representation

Where next

People also look at

Have a product where generation quality decides everything?

Get in touch — we'll work out what can be automated in your case.

I reply the same day, usually within a couple of hours.