From PDFMonkey to Aim Monkey: Building internal tools that actually help

One of the first features i worked on when starting my career was AIM's pdf generation tool. It was time to migrate off of PDF monkey's SaaS product to our own solution. we had to figure a way of maintaining the same templates we used with PDF moneky but reverse engineering the server side logic, this was quite the challenge on it's own, we managed to eventually do it but ended up with a extra friction and huge loss of productivity. The downgrade PDF monkey offered a developer portal, where you could have a side by side view of the template code you were working on, and a preview of the pdf on the other side. It had it's own cons (long waiting time, frequent errors, etc..), nevertheless losing it was a huge blow do developer productivity. Now there was no way quick way to preview the results of your template code as you wrote it, the only apparent way running the manually every time. There were also no history of reports generated were you could quickly get test data from. Developers need a tool where they could develop, test, iterate, commit. all things that were provided by PDF monkey If it exists, it's doable After successfully replacing the functionality of being able to generate pdfs from liquid templates, I was confident i could replace the great DX experience they offered was an even better one, here is how i did it. The challenging components In the backend To generate a pdf, we first combine report data with the liquid template code, generating an html page. Which we then transform into a PDF using a headless browser with puppeteer. Templates are just text files which we can edit and read with node's file system operations. Allowing the result to be returned as either html or pdf, Will allow switching between quick previews or final (but slower) previews. ## In the frontend We need a text editor, thankfully there are lots of available open source editors that can be used in the web, of those i picked the ACE editor. Displaying the html preview could be simply done with an , simple and quick without any need for packages. Displaying PDFs could be done with react-pdf, a wrapper around Mozilla's pdf.js, a pdf viewer for the browser. # And here is how it came together The benefits I got to do it! Way faster previews 30s -> 200ms, that's 150x, Lots of time and frustration saved with better DX. Eliminated quotas imposed by the previous SaaS, and prevented timeout issues, both previously out of our control. Saved some money. The ability to run this app locally, allowed us to introduce version control, being able to easily commit, revert and use git to our benefit. This experience led to ideas that greatly helped the occurrence of user reported issues. (we made decision that reversed some of our tech debt). Finally We managed to make this migration into something that fit us better, and lead to better decisions and use of our time.

Apr 22, 2025 - 17:19

From PDFMonkey to Aim Monkey: Building internal tools that actually help

One of the first features i worked on when starting my career was AIM's pdf generation tool. It was time to migrate off of PDF monkey's SaaS product to our own solution. we had to figure a way of maintaining the same templates we used with PDF moneky but reverse engineering the server side logic, this was quite the challenge on it's own, we managed to eventually do it but ended up with a extra friction and huge loss of productivity.

The downgrade

PDF monkey offered a developer portal, where you could have a side by side view of the template code you were working on, and a preview of the pdf on the other side.

It had it's own cons (long waiting time, frequent errors, etc..), nevertheless losing it was a huge blow do developer productivity.

Now there was no way quick way to preview the results of your template code as you wrote it, the only apparent way running the manually every time.

There were also no history of reports generated were you could quickly get test data from.

Developers need a tool where they could develop, test, iterate, commit. all things that were provided by PDF monkey

If it exists, it's doable

After successfully replacing the functionality of being able to generate pdfs from liquid templates, I was confident i could replace the great DX experience they offered was an even better one, here is how i did it.

The challenging components

In the backend

To generate a pdf, we first combine report data with the liquid template code, generating an html page. Which we then transform into a PDF using a headless browser with puppeteer.
Templates are just text files which we can edit and read with node's file system operations.
Allowing the result to be returned as either html or pdf, Will allow switching between quick previews or final (but slower) previews. ## In the frontend
We need a text editor, thankfully there are lots of available open source editors that can be used in the web, of those i picked the ACE editor.
Displaying the html preview could be simply done with an , simple and quick without any need for packages.
Displaying PDFs could be done with react-pdf, a wrapper around Mozilla's pdf.js, a pdf viewer for the browser. # And here is how it came together

The benefits

I got to do it!
Way faster previews 30s -> 200ms, that's 150x, Lots of time and frustration saved with better DX.
Eliminated quotas imposed by the previous SaaS, and prevented timeout issues, both previously out of our control.
Saved some money.
The ability to run this app locally, allowed us to introduce version control, being able to easily commit, revert and use git to our benefit.
This experience led to ideas that greatly helped the occurrence of user reported issues. (we made decision that reversed some of our tech debt).

Finally

We managed to make this migration into something that fit us better, and lead to better decisions and use of our time.