Building ease

Writing HTML isn’t hard, but it is tedious and necessary since HTML is a foundational internet technology. At my last organization, my team was tasked with generating custom HTML templates for up to seven different emails, depending on the configuration. The only difference between the templates was the copy choices made by the partner. Even so, hand-coding those copy changes across seven documents was time-consuming and error-prone. Things would be miscopied in one email but not in another, and it was hard to keep track of what had changed because it’s easy to gloss over small details when doing repetitive work. I wanted something better for my team, and I knew I could build it.

I looked into the developer documentation of our email marketing platform, Iterable, and saw that it had an endpoint capable of receiving a payload of data to generate new campaigns based on a given template. I knew I could write a tool to integrate with this endpoint and make creating new campaigns a snap.

Our primary monolith was written in Ruby on Rails and already housed most of our program configuration data. I created a new model to store the email copy choices that our partners made for their programs. Because I was already familiar with Rails, it was easy to extend the functionality of our admin panel to include this feature. I added logic to the program show page to render a button that would open the form for inputting campaign data if there was no associated campaign data. If the data did exist, the page would render that data and give the option to make changes. Extending this functionality within the tool the team already knew made adoption of the new process easy. Once the campaign copy data was saved within our application, the user could click a button to generate the campaigns. They would select which campaigns to generate, and after clicking “Generate,” they would see the freshly minted emails in our email marketing platform, ready to send.

Under the hood, our Rails monolith used a plain old Ruby object to package the campaign data and send it to Iterable to generate the HTML for the new campaigns. In this way, a process that would take hours and require painstaking attention to detail became automated by the power of computers. By creating a single source of truth for this information and then communicating it programmatically, we were able to reduce errors and make it easier to configure what our customers needed. More importantly, this tool created a layer of abstraction between our templates and our copy, which allowed the team to better support different configurations. For instance, if a customer wants a different design or different copy, we can build our templates out to quickly change things as specified by the customer’s needs.

Building a tool to automate campaign creation with a single source of truth for copy configuration dramatically streamlined our process. By leveraging Iterable’s API and integrating it directly into our existing Rails monolith, we eliminated the tedious and error-prone task of manually editing multiple HTML templates. Even better, we were able to abstract the underlying templates from the copy itself, making it faster and easier to support diverse configurations for different customer needs. The end result is not just time saved for the team, but also a more flexible, reliable workflow that keeps campaign data in one place while ensuring each message is accurately generated and ready to send. Most importantly, I was able to build something that made an arduous task easy—and that is my favorite kind of thing to make.