Kelvin Liu is a Founding Engineer and tech lead at Beacons. We talked to Kelvin about how Beacons builds email marketing products, their workflow for creating email blocks in React and testing through Litmus, how Litmus compares with other email testing and development tools like Parcel.
- Can you start by telling us about yourself, your role, and what led you to need a tool like Litmus?
- Were there other tools that you looked at besides Litmus, or have looked at since bringing it on?
- Can you talk us through the workflow of how you use Litmus, both individually and with the team? What are the features you make use of in the product?
- Litmus only gives you a certain number of previews—either 1K previews a month or two depending on which pricing plan you're on. Did you have any experience going over that limit?
- You said you haven't built any email blocks in a while, so has there been any continuing need for Litmus or reason to use it since?
- You mentioned using the Litmus code editor feature at times. Can you talk us through the kinds of stuff that can be handled in the native Litmus code editor vs. what can't?
- With regard to Parcel, would you characterize it as a direct alternative to Litmus, or is Parcel more of an email IDE kind of thing?
- With a lot of folks who use Litmus and Parcel, there's this very predominant copy and paste of code into Litmus or Parcel to do all the accessibility checks and QA. Did you also use this copy and paste type workflow?
- Is there anything else you’d like to mention about Litmus or this kind of product space that we didn't talk about earlier?
- You said you were on the basic plan. Do you know people have accounts, or is it just a one login kind of thing?
- One thing we talked about with some folks was that there are so many different Gmail, Apple, Outlook, but then the long tail of those is crazy. Do you find yourself limiting your previews to the most common kind of email clients?
Can you start by telling us about yourself, your role, and what led you to need a tool like Litmus?
I'm a tech lead at Beacons. I lead our email marketing products. We started really building it out at the beginning of this year and we did not use Litmus, as far as I know, before this. I'm not the one who brought it in as a tool for us to use but I had heard about it and read a couple articles about how to properly code emails to make sure they render on all the email clients out there.
Once we started testing it out, we really saw the value that it provides for us. We're making an email builder for others, so we need to make sure that the things that we let people build actually look like we want them to, across all email clients. Every change we make, every new feature to what we call the email blocks—you build a message out of email blocks—and all of these things that we're building, we'll just double check through Litmus that they render as we intend them to.
Were there other tools that you looked at besides Litmus, or have looked at since bringing it on?
I looked really briefly at this tool called Parcel. I signed up for the trial and gave it a shot. It had this email validator and stuff and I took a pretty quick look, so I honestly don't feel like I can really give a good evaluation of it other than I know it's out there and I used it for a minute, basically.
Can you talk us through the workflow of how you use Litmus, both individually and with the team? What are the features you make use of in the product?
Workflow wise, we haven't really developed any new blocks in a while because we pretty much have coverage of the basic things you would need out of building an email. We've got a rich text block, images, links—all the basics. For a long time now, all of our changes to these blocks have just been improvements—different layouts that we offer and stuff like that.
But the workflow, when it comes to Litmus, is really we build our product in React. We've coded all of our email blocks in React and we have them generating the email HTML that actually gets sent to clients. Then, during that development process, we'll just send an email to Litmus. They have this feature where they give you sort of an inbox that you can send test emails to, and then, it'll automatically generate previews for QA and Gmail, Apple Mail, Outlook—all the popular clients that we support. Then, we'll just spot check those.
There's also this pretty cool feature where directly in Litmus, you can make quick edits to the actual code, so we don't need to go back and update our code. We can just try some stuff out inside of Litmus itself and then, generate previews once again. That is most of it. There's some other things like when we were first starting, there was just a checklist or some basic validator for the email. I think that they're just based on best practices—making sure the links go somewhere, the images aren't too big, too small, stuff like that.
Litmus only gives you a certain number of previews—either 1K previews a month or two depending on which pricing plan you're on. Did you have any experience going over that limit?
I know we hit the limit at least once definitely when we were first building out a bunch of this stuff because we were testing our code so often. I believe we only use the basic plan though. I'm not super familiar on the billing side of this stuff but it seems like there's a decent amount of leeway where if you hit the limit, you can still use Litmus and generate previews. But you do get this banner that tells you that you're over the limit, and you've got to explore the plans. I'm assuming if you go grossly over, you've got to upgrade.
You said you haven't built any email blocks in a while, so has there been any continuing need for Litmus or reason to use it since?
Right now, we're actually rebuilding our own email builder to be a lot more interactive and in doing that, we're kind of overhauling the code that powers these email blocks to add that interactivity.
We are still using Litmus just to make sure that we don't add in any bugs to the actual emails that get sent out. So we're definitely not using it as much as we used to, but we still do find some value in it just to have that confidence that we can make this change and it won't negatively impact the emails that creators have already built or the ones that they're planning to build.
I've only used their code editor. So, it basically just gives you a bunch of HTML that either you wrote or you sent from an email that came from somewhere. My main use case for that is just quick edits that I can make.
There's a live preview on the side of the screen beside the HTML code, so I can see directly what happens based on the stuff that I change. Then, there's another tab next to that preview that lets me, I think it will just send it out as an email and regenerate those QA email previews in separate clients.
I don't really need to do it, but I feel like it's just a bit quicker of a feedback loop versus me opening up my own code, editing my own files, and then sending another email from my machine to the Litmus inbox.
With regard to Parcel, would you characterize it as a direct alternative to Litmus, or is Parcel more of an email IDE kind of thing?
I think it's a bit borderline to do that. But I would definitely agree with what you said where it definitely felt more like an IDE for emails. If I remember right, there were some starter email templates that it came with, very much geared towards building your email directly in Parcel, which didn't exactly align with what we're doing because at Beacons, we’re building the email.
For creators, we're writing code to build that code. So it didn't quite fit in as well as with what we needed although I know Litmus does offer that to some extent with their code editor. I know you can start drafting up emails from the ground up in Litmus as well. So I think there's some overlap, but to me, Parcel definitely does seem more like an IDE.
With a lot of folks who use Litmus and Parcel, there's this very predominant copy and paste of code into Litmus or Parcel to do all the accessibility checks and QA. Did you also use this copy and paste type workflow?
Not really, no, because we really sort of discovered the email-sending method, first. So the way we store emails on our platform aren't even really in HTML because we sort of abstracted that stuff away into blocks. We have blocks, and then all the properties that go into those blocks. The result you get is in HTML, but it's not super easy to copy that output into a place where we could paste it into one of those tools.
Is there anything else you’d like to mention about Litmus or this kind of product space that we didn't talk about earlier?
I think Litmus just seems like a pretty solid tool in terms of reputation because of their blog posts. At least for me, I remember having issues with images rendering in specific clients, and there would literally be a blog article on Litmus saying how to render images on this client. I was like, “Great! This is exactly what I need.”
They just have a lot of, I guess, knowledge sharing, knowledge put out there for people building emails. It's a very good way to market their own tool. At the end of each article, it's like, "Oh, if you need deeper support or more support, or anything you need related to email, just sign up for Litmus, and try it out and stuff."
You said you were on the basic plan. Do you know people have accounts, or is it just a one login kind of thing?
We only have one seat and then, as far as I know, there's just one login.
One thing we talked about with some folks was that there are so many different Gmail, Apple, Outlook, but then the long tail of those is crazy. Do you find yourself limiting your previews to the most common kind of email clients?
That's definitely an interesting thing. We do, do that. But I think, recently, we've also just limited to the trickier platforms. Outlook, in particular, has given us a lot of trouble for certain things. Email clients are still not that great in terms of support, but Apple Mail and Gmail are fairly solid where at this point we have high confidence that the changes we make—and knowing what we've gone through in the past—we're pretty confident that it won't break stuff. We'll still check, but maybe not across all versions on all supporting systems and stuff.
This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.