When we started FoxyUtils , our collection of online tools to convert and manipulate PDF files, we had a single server which converted the documents on the fly. Over the years our backend had to become more sophisticated andAs the number of conversions grew, the first thing we implemented was deploying and distributing FoxyUtils on a number of servers around the world. The nature of such solutions is quite complex and it is important to split the stack into small components which serve particular responsibilities.Another benefit of this approach was the ability to delegate various components to different members of the development team, making the team more efficient and the platform more reliable.Today we have dedicated conversion servers and a process which delegates the tasks between them. We built our process by going to the drawing board and defining the components required to support millions of conversions. Then we prototyped them. One of our developers vouched for the Go programming language and the team started experimenting with it. Very quickly we were up and running. And after some fine-tuning we had a codebase which was easy to read, deploy and build.It only takes seconds to build the codebase. And our dependencies are all vendored with a simple built system we created ourselves, based on the one used in Camlistore Once the infrastructure was built, we tried to find a PDF toolkit for Go, but found nothing that fulfilled our needs. As a result, we started putting resources into developing a PDF toolkit for Go called UniDoc.after pushing it into production a few weeks earlier.We are regularly updating it with bugfixes and planning new features.We are looking forward to receiving your pull requests.Curious to find out more? Sign up for our Unidoc mailing list for developers.