Storybook PrintEngine
From checkout to printing press for a personalised book brand selling in two countries. I built the storefront and an automated 300 DPI print pipeline, then replaced hand-coded page layouts with a declarative book engine and a visual builder.
Page preview render
Full page generation, including every character variant
Generation time roughly halved versus the headless-Chrome renderer
Launching a new book is now a configuration task, not an engineering project
Thechallenge
A parent picks a title, tells the site about their child, pays, and a printed book arrives. Behind that is a full business: two currencies, two payment providers, tax invoices, shipping rules and an order pipeline that has to end in a print-ready file with bleed and trim marks, every time, with no designer involved.
The first version worked, but every book was hand-coded and rendered by screenshotting pages in headless Chrome. Adding a title meant an engineer writing layout code, and the renderer was slow, memory-hungry and failed in ways that were hard to reproduce - nowhere near ready for the catalogue the business wanted.
How Iapproached it
Commerce as data
One codebase serves both countries, with pricing, currency, shipping and tax handled as data, and signature-verified, idempotent webhooks for both payment providers so retries and late events can never double-charge or un-pay an order.
Engine, not books
I replaced the headless-Chrome renderer with a schema-driven engine. Each book is one definition - variables, characters, customer questions and pages built from layers with structured visibility rules. The same definition drives the live browser preview and the server-side print render.
A builder for non-engineers
A visual admin tool with a canvas, layer inspector, rule editor, an asset matrix for character variants, localised text and validation. Launching a title became a configuration task.
Rendering as its own service
I split rendering into a standalone service with an authenticated API, a job queue, per-order signed requests and a sweeper that recovers stalled renders, so the storefront never shares memory with a heavy print job.
Highlightsworth showing
- (01)
Paid orders flow through a queue that renders every page at 300 DPI, assembles a press-ready PDF with bleed and trim marks, and stamps a scannable order label into the bleed.
- (02)
Preview and print resolved from one source of truth, removing a whole class of "preview doesn’t match the book" bugs.
- (03)
Print-grade details solved in code: clean font names for prepress tools, a patched font library for Indic and accented names, and deliberate RGB output after finding that naive CMYK conversion inverts colours in the printer’s software.
- (04)
Stable job ids so webhook retries collapse into a single render, while admin re-renders get their own.
- (05)
Legacy books migrated by a converter, and the old headless-Chrome path deleted outright.
Have a project like this?
Tell me what you’re building or what’s broken. I’ll tell you straight whether I’m the right person for it.