Continuous Testing for Email Reliability

Diving deeper into

Avi Goldman, founder of Parcel, on the email developer experience

Interview
That's what happens in email all the time.
Analyzed 7 sources

Email is still a brittle production surface, not a finished publishing channel. A team can ship a template that looked correct last week, then wake up to Gmail or Outlook rendering it differently after a client update, with no alert until customers complain. That is why email teams still rely on repetitive preview checks, screenshot tests, and manual QA, and why automated monitoring is the missing layer between building an email and trusting it in production.

  • The workflow is unusually fragile because the same HTML is interpreted by many clients with different rules. Podia used Litmus to inspect old Outlook, Gmail iOS, and other clients specifically because modern web assumptions do not hold in email, and even small rendering changes can force repeated compile and retest loops.
  • Most teams still test at send time, not continuously after send. Parcel layers link checks, image checks, accessibility checks, inbox previews, comments, and approvals into the build flow, while Litmus now offers ongoing monitoring through Email Guardian, which reflects the market moving from one off previewing toward always on QA.
  • The practical fix is component based email systems. At Figma and inside Parcel's roadmap, the goal is to change one shared button, background, or layout component and have every template inherit the fix, instead of hand editing dozens of HTML files after each Gmail or Outlook breakage.

The next step in email tooling is continuous testing tied to shared components and the sending platform. That turns email from a fragile batch process into something closer to software deployment, where regressions are caught automatically, fixes roll out across templates, and teams stop learning about broken emails from end users first.