How our PrintOps system works

A multi-lingual, global, zero inventory network, synced with a single command that prints thousands of books a day

At Lost My Name we print a lot of ‘Print on Demand’ (POD) books. Over 146,000 at the time of writing. Yesterday we printed over 3000 in one day, our best day ever.

Designing a POD system to operate at this scale poses significant engineering challenges.

• Scale. We need our system to be able to grow quickly in order to satisfy the rapidly growing demand for our books. We’re currently experiencing sales growth of 20% week on week in the run up to Christmas.
• Speed. We have customers all over the world, and we need to ship their books to them as quickly as possible.
• Quality. We want every customer to get the same high quality book.
• Agility. We want to be able to easily update and improve our books when our writers and illustrators have new ideas for story segments or improvements in layout. We’re already on our sixth iteration of Lost My Name.
• Variety. We want to be able to sell our books in multiple languages, with different cover and gift wrap options.

All this adds up to a significant engineering challenge that we solve with two key ideas.

1. A global, standardised production network

The first big idea is to try to get total consistency in delivery across all our print houses, and to ensure we have a good distribution of locations.

We currently have a global network of print houses (two in the UK, one in the US and very soon one in Australia), and every print house is capable of printing every variety of POD product we sell — soft back, hard back, all languages.

We then create commercial arrangements with each print house where they are paid per book shipped within a specific timeframe. We’re aiming for a zero inventory business, which reduces waste and keeps costs very tightly tied to demand.

One of the mahoosive HP indigo printers used by our print houses

We currently allocate orders based on physical proximity to the shipping address of the customer and try to ensure the shortest delivery time possible. In the future we’d like to build a bidding system in to our print house supply chain to help manage supply and demand more efficiently.

2. A single, synced, asset pipeline

The second thing we do is run a single centralised system for managing the assets that make up the POD book that allows us to sync changes to our print houses with a single command.

Before we explain how this works, its important to understand the nature of the POD book we create at Lost My Name.

Currently, a Lost My Name book is made up from a combination of several different story segments, each of which represents four high quality, full colour spreads. The various segments we have are:

• 28 story segments for every letter in the alphabet
• 3 ‘helper’ story segments
• 1 bridge story segment
• We have an intro, an outro and a cover for every book

This is a total of 448 high dpi images for the actual POD book, plus 290 low dpi images for the preview we offer on our website.

In addition, with every new language we add that figure increases one fold. For example, here’s our index of British English book assets

And here’s our index of German assets

Each page of the high quality size image is around 5MB, so thats 20MB per segment. The average book we print has 5.6 letters plus an intro and an outro (four pages each), so that’s 142MB per book.

As mentioned earlier, we over 3000 books yesterday (and we’re growing 20% week on week right now).

If we operated a system that rendered each book on our servers that would mean sending 397GB of images over the internet yesterday — a significant cost. Over the lifetime of the business so far, that would be around 16TB of data.

So instead, we operate a system whereby each print house hosts a synced version of our book assets locally, and we just send them .csv files once the order is completed on our website.

Once the print house server receives the .csv file it then gathers the correct story segments that make up the child’s name, puts them in the right order and renders out the unique PDF to be printed.

Here’s what the system looks like:

One of the coolest things about this design is the workflow we’re developing to allow our writers and illustrators to easily update our book — the ‘agility’ challenge mentioned at the start of this piece.

Today, if you want to pull down all the assets onto a local machine you can do this with a single command (provided you are running our Zebra sync app):

$ bin/sync

And if you make changes and then want our global network of print houses to start printing your improved story immediately, you simply type:

$ cap production sync_assets

This is really awesome and something we’re very excited about — it means that updating and improving our book is closer to the git workflow used by our software engineers.

How can we improve?

Our entire system is very much work in progress . We’re learning as we go, and would love to hear from other PrintOps specialists about how they do things on twitter, or in the comments— and if you’d like to help us more directly we’re hiring!

Some of the obvious things we’d like to do next include:

• A bidding system for print houses to help manage demand better
• Better management of our PrintOps test environments
• The ability to offer our system from the cloud — some print houses are already requesting this
• Version control on our publishing workflow
• More instrumentation in the print houses so we can expose the awesome POD process to customers

P.S — Follow us on twitter for more updates on how we’re making Lost My Name and if you enjoyed this piece please hit recommend below. Ta!