Litmus Not Ideal for Product Teams

This says Litmus is strongest as a high frequency workflow for people who hand code and QA lots of one off campaigns, not as a permanent operating system for a product team building one reusable email engine. Podia used Litmus to catch the hard rendering bugs early, then saw usage fall once its underlying template system stabilized and the same fixes started applying across many templates.

• Podia was compiling its own email markup with Roadie, pasting the generated HTML into Litmus, and paying per preview, so Litmus was mainly a bug finding checkpoint, not the place where the team actually built emails. That made it useful during setup, but cumbersome as an everyday workflow.
  1 sacra
• Figma uses Litmus in a more classic way, for previewing new templates and major layout changes, while relying on Parcel for the day to day coding workflow. That split shows Litmus fits best when previewing cross client rendering is the main job, not when collaboration and code authoring are the center of work.
  2 sacra 4 sacra
• Beacons sits between those two cases. It also builds an email product, but still checks new blocks and layout changes in Litmus because one rendering bug can affect every creator using that block. Once the core block set was built, testing narrowed to the trickiest clients like Outlook instead of every client on every pass.
  3 sacra

The direction of travel is toward narrower, more targeted use of Litmus. As more email teams standardize on reusable components, block systems, and specialized coding tools, cross client previewing becomes a periodic QA layer around the template engine, while the daily center of gravity moves to the editor, the component library, and automated checks.