Choosing Which Email Breakages Matter
Jason Charnes, Staff Product Developer at Podia, on building an email editor
This reveals that shipping an email builder is mostly an exercise in choosing which breakages matter. Podia was not trying to make every message pixel perfect in every inbox ever made. It narrowed the problem to the clients creators actually use, wrote emails in very old school HTML with inlined CSS and tables, then used Litmus screenshots and Can I Email support data to catch the big failures before launch.
-
Podia treated email rendering like browser QA, not like a product feature to perfect forever. The workflow was compile HTML, paste it into Litmus, preview key clients, fix bugs, and consciously drop edge cases like Lotus Notes when the engineering cost was too high.
-
This fits Podia’s broader product strategy. It builds the creator facing workflow that helps users sell, but buys underlying infrastructure when a vendor already solves the hard technical problem well enough. In video, Podia made the same choice with Wistia, Zoom, and YouTube, and email rendering followed the same logic.
-
Other teams building email products follow the same pattern. Beacons also used Litmus mainly to spot check Outlook, Gmail, and Apple Mail after generating email HTML from code, which shows that for builder products, the job is reliable coverage on the painful clients, not exhaustive support on every long tail environment.
Going forward, email builders will keep converging on a practical standard, support the major clients, avoid unsupported CSS, and automate QA around the worst offenders. That favors tools like Litmus, and reference layers like Can I Email, because they turn a messy compatibility problem into a manageable checklist instead of a full time specialty team.