Parcel treats email like software
Mark Robbins, software engineer at Customer.io, on the email coding stack
Parcel won attention because it treated email creation like real software development, not like a side feature inside a testing tool. Teams could write email code in a VS Code like editor, catch errors as they typed, preview changes live, collaborate in one place, and reuse components so one brand update could flow across many emails. That solved a messy workflow that had often been split across editors, shared files, Git workarounds, ESPs, and Litmus.
-
The core gap was workflow. Before tools like Parcel, teams often built emails in Atom, VS Code, Dropbox folders, or internal Git setups, then copied HTML into Marketo or another ESP. Parcel bundled code editing, QA checks, comments, approvals, and inbox previews into one workspace.
-
The product stood out most with email developers. Parcel was built developer first, with autocomplete, code formatting, inspect element, focus mode, autosave, accessibility checks, and reusable components. Litmus was still stronger in testing for some teams, but it was usually treated as a preview tool that happened to include editing.
-
That distinction mattered strategically for Customer.io. Buying Parcel let Customer.io pull coding and testing closer to the sending platform, which creates a path from manually exporting email HTML to a future where updating a shared component changes every downstream message automatically inside the ESP.
The next step is turning email from a pile of copied templates into a connected system of components, review, and automatic sync with the send platform. If that happens, the winner will be the company that owns both creation and delivery, because it can remove the last manual step and make every campaign update faster, safer, and more on brand.