Email HTML as Compile Target

Diving deeper into

Jason Charnes, Staff Product Developer at Podia, on building an email editor

Interview
We used Roadie.
Analyzed 6 sources

Using Roadie shows that Podia treated email HTML like a compile target, not like final source code. The team wrote simple HTML and CSS first, then let Roadie rewrite that code into inline styles, because many email clients ignore or strip modern CSS. That made browser based code editing less useful for final fixes, since the version that actually shipped was the machine generated output, not the hand edited draft.

  • Roadie sits in the build step. It takes CSS from style blocks and applies it directly onto each element as inline styles, which is the safest format for old Outlook versions and other inconsistent inboxes. That is why Podia kept returning to compile, paste, preview, instead of trusting edits made inside Litmus.
  • This also fits Podia's broader product strategy. Podia builds the creator facing workflow that matters to customers, but buys infrastructure pieces that are good enough and hard to maintain, like video hosting, email delivery, and here, email CSS processing. Roadie was a plumbing choice, not a product differentiator.
  • The tradeoff is speed versus certainty. Dedicated email coding tools like Parcel are better for writing and inspecting code, but Podia's problem was not just authoring. It was making sure the compiled email survived the bizarre rules of Gmail, Outlook, and mobile clients, which is why Can I Email and Litmus mattered more than an in browser editor alone.

The next layer of tooling in email will combine these steps into one workflow, authoring, compile, support checks, and preview. As creator platforms keep adding built in email, the winning setup will hide this messy conversion work from developers while still producing inbox safe HTML every time.