Parcel as an Email IDE

Diving deeper into

Kelvin Liu, Founding Engineer at Beacons, on the email product development process

Interview
it definitely felt more like an IDE for emails.
Analyzed 6 sources

Parcel mattered because it treated email like software, not like a finished asset to preview at the end. For teams like Beacons that already generated emails from React components, that meant Parcel was most useful when an email developer wanted a dedicated place to write, store, test, and reuse email code. Litmus fit later in the workflow, once HTML already existed and the main job was checking how it rendered in Gmail, Apple Mail, and Outlook.

  • The workflow split was practical. Beacons built email blocks in React, generated HTML, then sent test emails into Litmus for screenshots across major inboxes. That makes Litmus closer to QA infrastructure than a daily coding environment.
  • Parcel was built around the developer loop. It combined a code window, live preview, fast test sends, snippets, components, and checks like accessibility. That is why email developers often described it as the inverse of Litmus, creation first, testing second.
  • This distinction also maps to team structure. Figma used Parcel for marketing ops to build and collaborate on marketing emails, while product and engineering kept Litmus for transactional email testing. Different teams bought each tool for different jobs.

The market is moving toward more developer style email workflows, where reusable components replace one off HTML files and testing becomes one layer in a larger build system. That favors products that sit earlier in creation, but preview and QA tools like Litmus remain deeply embedded wherever teams need a trusted final check before send.