Parcel as Email Creation Layer
Avi Goldman, founder of Parcel, on the email developer experience
The strategic opening for Parcel is not replacing the whole email stack, it is becoming the system where teams actually build and update emails before those emails get pushed into many other systems. In practice, brands often split marketing and transactional sends across different tools, keep customer data in a CDP or warehouse, and still rely on manual copy and paste into ESPs. That fragmentation makes a creation layer valuable, because one place for code, previews, approvals, and reusable components can sit above the mess without forcing a full rip and replace.
-
Real teams already run mixed stacks. Parcel itself used Customer.io for marketing email and SparkPost for transactional email. Figma used Parcel for marketing email creation, while product and engineering kept Litmus for transactional testing. The point is not one suite, but stitching together specialist tools around one workflow.
-
The pain is mostly in creation and maintenance, not just sending. Before tools like Parcel, teams worked in Atom, Dreamweaver, local repos, or raw HTML files, then moved code into Marketo or another ESP. Parcel wins by centralizing live editing, previews, QA checks, comments, and reusable components in one place.
-
This also explains the Parcel and Litmus split. Litmus is strongest as a testing and preview product, while Parcel is strongest as an email creation product with testing added on. That leaves room for both to coexist inside one company until creation, testing, and delivery are tied together more tightly.
The next step is deeper sync into sending platforms, so changing one component updates every email without manual export. If that happens, the market shifts from separate coding, testing, and ESP tools toward a more unified message creation layer, and the company that owns that layer gets much closer to owning the broader marketer and developer workflow.