We were using Mandrill for quite some time. The amount of sending event-triggered emails for us was very low. We are a small and cost-conservative organization. So we decided to stick with Mandrill’s Free Plan until it fulfills our needs. We sort of made Mandrill a standard in ColoredCow. Since it’s so easy to configure and use, we passed on our Mandrill expertise to everyone. Be it a new hire or intern, everyone became an instant fan.
A couple of months back, we launched CodeTrek which includes sending emails for subscription confirmations, admin notifications, form notifications, etc. Our free tier plan started to exhaust rapidly. With very less time in our hand, we figured it’s best to go for the MailChimp’s monthly plan and an email bucket in Mandrill (renewed every month). A month later, the statistics showed we had used less than 5% of the bucket capacity, yet we have to pay for the whole bucket again. It was the time we decided to look for an alternative.
Most of the people at ColoredCow follow FreeCodeCamp’s official blog on Medium. I am a personal fan of the non-profit as it helped me greatly to learn how to code during my college days. We came across their article on Mail For Good. It’s built on top of AWS Simple Email Service. Reading about SES, it didn’t look any more complex than Mandrill. Adding TXT and CNAME records and verifying our domain came in handy. Thanks to Mandrill we had done this before and knew all the technical jargons. Setting up SES was a piece of cake.
coloredcow.com is built on WordPress and the best thing about WordPress is you generally find an existing plugin that can fulfill your requirements. We found one too. WP SES. It was compatible with the latest WP version, has decent downloads and the author is actively maintaining it. Nothing could be better. We downloaded it immediately and started configuring. After verifying our AWS account and setting up some other minor things, we tested the mails and they went smooth. Wow! The time was to start replacing our Mandrill calls from the code. The plugin overrides default wp_mail function. So sending emails were even easier. We started replacing all the CodeTrek email triggers with wp_mail. Soon we realized we can’t.
The first problem was a custom sender email. We cannot configure custom senders depending on which module shoots the mail. For example, the emails from CodeTrek are sent from codetrek@coloredcow.com while from other places it was support@coloredcow.com or careers or internship and more. The plugin didn’t support this. We also tried overriding the plugin’s functionality but couldn’t efficiently. Hence, we decided to write our own plugin.
The second problem was mail templates. We were using templates for basically every communication. They are handy and comes with a beautiful interface. AWS has an API for email templates but investing time on another new service didn’t seem a feasible route. We knew that would delay our deadline. So we had to figure out an alternate approach that should be integrated into our custom plugin.
We started off by reading the official AWS SES documentation and the SDK usage. We installed the SDK using composer, followed the steps mentioned in the documentation and the sample test emails went smooth. Just like Mandrill, everything was straightforward. Now to add it to the codebase, we realized it’s best if we program it as an external tool/plugin and isolate its core logic from other areas. Following that structure, we brainstormed on how this external plugin is to be used from the application.
We created a documentation of that structure, and how someone can use SES directly using our plugin. How to define email subject, body or even an HTML template, which functions will be called when and many more. We wrote down everything in a single google doc. Once the plugin was complete, we used our documentation and started replacing and testing Mandrill calls one by one. In less than a week, we replaced each Mandrill call, cleaned up composer.json, tested on our dev box and finally launched it to Production.