Tell us a little bit about the history of htmlemail.io. How did the idea come about? Why did you decide to start working on it? #
A couple of years ago I created a simple responsive email template which I open sourced and put on GitHub. When I shared it with the community it got some traction and I realized that while just a simple template, this solved a big pain for developers. Over the next couple of years I open sourced a few more templates as well as my (Grunt) workflow for creating them.
Then I started writing about what I had learned. I published blog posts about sending email, building email and responsive email (which I later accumulated in one long post for Smashing Magazine). These posts received positive feedback and I started getting requests to talk about email development at conferences. I had the opportunity to speak at several developer conferences including O’Reilly Fluent Conference in San Francisco and Litmus Email Design Conference in Boston.
I got to this point where I had shared a bunch of knowledge and open sourced a bunch of code. Thanks to the feedback (and website traffic) I felt I had a good amount of validation to “productize” a pack of email templates that would solve 80% of use cases for startups and developers. I invested some time in getting the templates up to a quality standard and testing them across the major email clients then launched HTML Email.
What has the response been like from the email community? #
Fantastic. In 18 months we have over 800 customers. On launch day we were the most hunted website on ProductHunt. Honestly I wasn’t expecting it to be as successful as that. Earlier in the process I had plans to make video tutorials, write a book, offer some more advanced tooling etc. and in the end I decided just to ship what I had, the email templates. Turns out all that stuff, while it would be nice to still offer these at some point, they weren't necessarily needed for launch.
I think having the shared knowledge out there in blog posts as well as free templates has worked well as a channel. A lot of our referrals come from these blog posts and GitHub. Many developers will read the articles, try the free templates, and have faith that buying the more “polished” pack of templates are worth it. If they’d rather not spend the money or don’t have a budget they can invest a bit of time in looking at the open source workflow and figuring out how to make the templates themselves.
What has the project taught you about email development? Anything surprising or particularly challenging that stands out? #
Over the years I’ve learned that 99.99% of developers do not like dealing with email. Cross client support. Inlining CSS. Using tables. Not something a typical developer has desire to deal with.
Of course all companies, apps, services send emails. So at some point someone has to set them up. Usually that someone wants to get in and out as quickly as possible. Sure there are companies that see the full potential and ROI of email and invest in a team. But most teams, especially early on, have a long list of other priorities and for email they want a quick solution that works.
So they’re not going to set up their own email infrastructure. They’re going to use an easy to use plug and play API solution like Postmark. Similarly they don’t want to spend weeks trying to learn how each email client renders HTML, what works and what doesn’t work.
That’s where HTML Email comes in, 10 high quality email templates that will get you up and running very quickly. Most customers say they’ll have their email templates live in less that 24 hours. It saves their developers days or weeks of pain staking agony trying to get their emails working and tested across the major email clients.
What’s next for you? What are your plans for the site and the templates? #
The templates are doing great. I follow up with every customer to make sure they’re able to get the templates up and running and to listen to their feedback. One thing I realized early on is the website lacked a way to retain users so I’ve tried a couple of things to address this.
We started writing more content aimed at developers, in particular email service provider integrations. As well as a super post about integrating with Postmark you’ll notice we now have how-to tutorials for several other ESPs.
I also created a CSS inliner tool. I was never really satisfied with the standard of inliners out there so I made one to better suit the needs of email developers. It inlines in real time, offers a desktop and mobile preview and has some export options. This has seen returning users grow as email developers use it daily for their inlining needs.
In the future I plan to build out more developer and design tooling for email. It’s a niche area with a great community that I think most developers and designers would rather not have to deal with. It feels good being able to provide tools and content that enable these makers to produce emails of high quality quickly with minimal effort.