Why You’re Still Rebuilding Emails in Your ESP (And How to Stop)

I’ve been in email marketing for over 15 years, and I can tell you with absolute certainty: the rebuild problem is one of the most inefficient, frustrating parts of email production. Yet almost every team I talk to is stuck in the exact same cycle.

Here’s how it plays out: Your designer creates a beautiful email in Figma. It looks perfect—colors are spot on, spacing is clean, everything’s on brand. Then it gets handed off to someone (maybe a developer, maybe an email specialist) who has to manually rebuild the entire thing in Braze, Salesforce, Klaviyo, or HubSpot.

By the time it’s done, it doesn’t look anything like the Figma file. Colors are off. Spacing is wrong. Someone made a decision without checking the design, and now you’ve got brand inconsistency baked into your email. And the whole process? It took a week. That’s not an uncommon story—I’ve heard it from dozens of companies.

The Real Cost of Email Rebuilds

The rebuild problem isn’t just an inconvenience. It’s costing you time, money, and brand consistency.

First, there’s the time investment. A designer hands off work, then someone else (or a freelancer, or an email service provider) manually codes it up in your ESP. If that’s happening for 50+ campaigns a year across your team, you’re looking at hundreds of hours spent doing work that should be automatic.

Second, there’s the error rate. Human-powered rebuilds are error-prone. Copy gets lost, responsive styles break, dark mode rendering gets overlooked. By the time the email goes out, it’s not what your designer intended.

Third, there’s the resource problem. If you don’t have a developer on staff who knows email coding, you’re outsourcing to Email Uplers, Fiverr developers, or freelancers. That adds cost, adds turnaround time, and introduces inconsistency—different developers have different standards.

And fourth—maybe most importantly—your ESP template builder is probably bloating your code. The WYSIWYG tools in Braze or Salesforce aren’t designed to produce tight, responsive, dark-mode-ready HTML. They’re designed to be easy to use. The code gets heavy, your emails render inconsistently, and you hit file size limits that restrict what you can do.

The Design-to-Code Gap

Here’s what I think is really going on: There’s a huge gap between how designers think about email and how email developers actually build it.

Designers design in Figma. They think in terms of beautiful layouts, flexible fonts, and pixel-perfect positioning. Email doesn’t work that way. Email has rendering constraints, device limitations, and inbox quirks that designers often don’t know about. So they hand off designs that look gorgeous in Figma but don’t translate to email.

When someone tries to rebuild that in an ESP template builder, they either have to oversimplify the design to make it work in email (losing the original vision), or write custom code, which takes time and introduces risk. Either way, the original design gets compromised.

What Modern Email Production Actually Looks Like

We don’t believe you need to code email anymore. That’s not because we think developers are going away—it’s because the tools shouldn’t require coding in the first place.

Modern email production starts with a design system approach. Your designer creates email components in Figma that are built specifically for email constraints. Not beautiful mockups that hope for the best—actual components designed for how email actually works.

Then, those components feed directly into your template builder (whether that’s your ESP or something purpose-built like Composer). The designer isn’t rebuilding anything. The developer isn’t hand-coding anything. The email goes from Figma to your inbox-ready template in minutes.

The foundation here matters. We build on MJML, which is battle-tested across thousands of inboxes. It gives you responsive design by default, dark mode support, and dynamic content blocks without bloating your code.

Why This Matters for Your Email Workflow

When you cut the rebuild out of your process, everything changes:

Speed: Your campaign goes from design approval to live in your ESP in hours, not days or weeks.

Consistency: Because there’s no manual handoff, there’s no room for color shifts or brand guidelines to get broken.

Scalability: If you’ve got 50 campaigns in the pipeline, or 500, the time savings compound. You’re not adding headcount—you’re automating the process.

Quality: Your emails render consistently across inboxes. Dark mode works. Responsive design is built in. No surprises on send day.

Getting Started

The first step is recognizing that the rebuild is a problem worth solving. Some teams I talk to have been doing it the same way for years and they don’t even realize there’s a better option.

If you’re designing in Figma and rebuilding in an ESP, you’re leaving hours on the table every week. The tool should handle the translation automatically. Your team’s time should go toward strategy and creative thinking, not manual rebuilding.

That’s why we built what we built. We wanted to close the gap between design and email—not by asking designers to learn email code, but by building a tool that bridges the gap automatically.

The rebuild problem doesn’t have to be inevitable. It’s just the way things have always been done. And that’s exactly what we’re changing.