Scaling Email Development with MJML
Sean Kennedy, senior marketing ops analyst at Zapier, on his email development workflow
Moving Zapier to MJML was really a move from hand coding every email block to assembling emails from a higher level recipe, which is what made speed and consistency possible as the team grew. MJML is built to turn simpler markup into responsive email HTML, and at Zapier it cut emails from thousands of lines to a few hundred, which made debugging faster and gave the team a clean base for later layering on Parcel components, versioning, and review workflows.
-
Before that shift, Zapier was effectively managing emails as raw files in VS Code and shared storage. That works with two or three people, but breaks once seven or eight people are editing templates, reusing snippets, and trying to keep branding identical across campaigns.
-
MJML solved the authoring problem, not the collaboration problem. Parcel then added the missing layer, centralized files, reusable components, threaded feedback, and export tooling, so Zapier could keep coding in MJML while treating email production more like a shared software workflow.
-
This is the same pattern seen at other scaled teams. Figma also moved from individual code editors and file sharing to Parcel for shared editing, while Parcel itself was built around the gap between generic editors like Dreamweaver or VS Code and the needs of email specific QA, previews, and component systems.
The next step is that MJML becomes the foundation layer, not the full system. As email teams get larger and more cross functional, the durable advantage shifts to component libraries, automatic sync into sending tools, and workflows where marketers, designers, and developers can all work from the same source without touching raw HTML every time.