How to cut build time, protect brand, and ship accessible messages at scale — Stripo.email

Building emails isn’t getting any faster. According to the 2025 industry survey by Really Good Emails, teams now spend an average of 8.21 business days to launch a single campaign. Back in 2018, it was 5.7 days. More personalization, more devices, more client quirks, and longer approval chains all add up. Another study from Litmus found that 62% of teams need two weeks or more to finalize one email. Accessibility is also falling behind: a 2025 audit by the Email Markup Consortium showed that out of 443,585 emails, only 21 passed automated accessibility checks.

That’s why more companies are investing in email design systems (EDS). An EDS is a shared library of components, tokens, and rules that keeps design consistent, reduces QA headaches, and helps teams work faster. In this article, we’ll walk through:

• why email production is slowing down instead of speeding up;
• two different ways to set up an EDS — one inside an ESP and one built around portable modules;
• how JSON tokens connect design tools and email code without breaking in Gmail or Outlook;
• a 90-day rollout plan you can start tomorrow.

Key takeaways

1. The average email build time has grown to 8.21 days, making faster workflows a real need.
2. An email design system brings together tokens, components, and rules to speed up production and maintain consistency.
3. Two approaches dominate: Platform-embedded systems (e.g., Customer.io Design Studio) and modular systems (e.g., Stripo Smart Modules). Each has strengths and trade-offs.
4. JSON tokens help align design and code. Tools like Style Dictionary convert them into email-safe CSS, avoiding broken layouts.
5. Results: Shorter build cycles, lighter HTML, and stronger accessibility if components enforce the right standards.

Why teams need a system for email now

Email production has become slower, not faster. As we mentioned earlier, teams spend an average of 8.21 business days to get one campaign out the door, and in 2018, that number was 5.7. What’s changed? There are more rounds of approval, more personalization layers, and longer QA cycles.

(Source: from Mark Robbins’ presentation)

62% of teams need two weeks or more for a single email. About a quarter say they have as many as five different messages in production at the same time. That kind of load makes a repeatable process critical.

Accessibility is another gap. 443,585 emails and found that 99.89% had serious or critical accessibility issues. Only 21 emails passed all automated checks. That means almost every campaign sent today still risks excluding recipients.

Then there’s client support. AMP features only render in Yahoo Mail and Gmail, while Apple Mail and Outlook ignore them. CSS custom properties work in some inboxes but fail in others. To keep layouts stable, many teams end up compiling styles in advance and relying on progressive fallbacks.

(Source: from Mark Robbins’ presentation)

Takeaway: Every campaign carries a hidden time tax if there’s no shared system in place. An EDS helps teams cut that overhead by making design choices consistent from the start.

What an email design system means in practice

At its core, an email design system is a reusable set of tokens, components, and rules that keeps every campaign consistent and reliable across clients. Instead of starting from scratch each time, teams pull from a shared library that already has branding, accessibility, and rendering quirks baked in.

Mark Robbins’ approach with Customer.io Design Studio shows how this works in real life. It follows the same structure many designers know from atomic design:

• tokens define the basics like brand colors, type scale, and spacing. They live at the global level, so any change updates across all components;
• components cover both standard blocks (headings, buttons, columns) and custom ones that developers build once and marketers can reuse. Variants and typed properties keep edits safe. For example, a button might allow only approved colors or font sizes;
• rules act as guardrails. They can limit where certain modules appear or set conditions for when content displays. That way, the email stays on-brand even when multiple people contribute.

Tokens work best when stored in JSON. The W3C Design Tokens draft defines this as the standard format, making it easier to keep design and code in sync. A build tool like Style Dictionary can then translate those tokens into CSS that’s ready for email — no risk of relying on runtime features that some inboxes still don’t support.

Two mainstream paths to an email design system

There are two main ways teams set up their Email design system today. Both aim to cut build time and keep campaigns consistent, but they take different routes.

A system built inside the sending platform

Customer.io’s Design Studio is a good example of this approach. The visual editor and code view live side by side, so developers and marketers work in the same environment. Teams can drop in standard components or build custom ones that follow brand rules. Global styles, like colors and typography, apply across every message.

One advantage here is control. Developers can add validations or conditionals directly inside components, which means marketers only see safe options when editing. In 2025, Customer.io also introduced Design Studio GPT, which generates starter code for custom blocks. It’s a helper, not a replacement, so the code still needs review before going live.

A system built around the editor, portable across ESPs

The other route is to create a modular setup outside of a single ESP. Stripo’s module library and Smart Modules follow this path. Teams build and store reusable blocks, then use them across different platforms. The export options make this model a strong fit for agencies or brands that run campaigns in multiple ESPs.

In short, Embedded systems enforce rules inside one platform, while portable systems give more flexibility across platforms. Choosing between them depends on how your team works and where your emails are sent.

Trade-offs to consider

Both paths solve the same problem but in different ways. Choosing the right one depends on what your team values most.

• portability: A system that lives inside the ESP, like Customer.io Design Studio, works best if your team runs everything on that platform. The downside is lock-in: moving to another provider means leaving the system behind. With Stripo’s modular library, blocks can be exported to many ESPs, which makes it easier to stay flexible;
• governance: Embedded systems let developers enforce rules directly at build time. For example, a button component might limit font size or color choices, so marketers can’t accidentally break brand guidelines. In a portable setup, governance depends more on discipline and how well the ESP handles merge logic or personalization;
• team makeup: If your team includes developers who are comfortable writing or reviewing code, an embedded approach gives them more tools to define and control components. Content-heavy teams, or agencies working across multiple ESPs, usually get more value from a portable system with visual modules that non-technical users can handle.

JSON tokens for email: A working pipeline that won’t break in Outlook or Gmail

Design tokens only pay off if they can be used safely across email clients. The good news is that there’s a way to do it without running into the usual rendering issues.

1. Define tokens in JSON

Start with the Design Tokens Community Group (DTCG) format. Store brand colors, typography scales, and spacing values in JSON, ideally tracked in Git alongside your email code.

2. Compile with Style Dictionary

Use a build tool like Style Dictionary to translate those tokens into static CSS, SCSS, or inline values. For email, it’s best to resolve all values at build time. Runtime CSS variables (var()) look neat but still fail in many inboxes.

3. Apply tokens in components

In Customer.io, tokens can be applied through custom component attributes and inline styles.

In Stripo, tokens can be set as defaults or locked values inside modules.

4. Avoid raw CSS variables 

Support for CSS custom properties is inconsistent. Some webmail clients parse them, but many don’t. Precompiling to static values is the safer option.

5. Plan for fallbacks 

Keep a reliable HTML baseline first.
Add dark mode adjustments with media queries where support exists.
Treat AMP features as optional. Always provide plain HTML fallbacks since major clients like Outlook and Apple Mail won’t render AMP content.

Component library anatomy

EDS usually follows a structure borrowed from atomic design, scaled down for the inbox. Breaking things down this way helps teams stay consistent and avoid one-off styling.

• atoms: The smallest elements: headings, paragraphs, buttons, images, and spacers. Font sizes should stick to a defined type scale, and only approved colors should be available;

  

  (Source: from Mark Robbins’ presentation)

• molecules: Combinations of atoms that form useful content blocks. Examples include a text + CTA button, a badge paired with a short line of copy, or a testimonial card with image, name, and quote. Offering two or three presets per block is enough to cover needs while reducing custom styling;

  

  (Source: from Mark Robbins’ presentation)

• organisms: Larger structures that repeat across campaigns: headers, footers, preference strips, and legal sections. These should carry rules for placement and include required elements such as the unsubscribe link and company address;

  

  (Source: from Mark Robbins’ presentation)

• variants and properties: Each component should come with simple, named options for things like weight, size, or style. URLs and ALT text need validation at the authoring stage to prevent errors before the email even reaches QA.

Results teams can expect

Industry data shows that email production times keep rising. As we remember, the average build time has stretched to 8.21 business days. Teams that adopt a shared component library usually see those numbers drop. Robbins’ presentation highlights the same trend: lighter HTML, smaller file sizes, and more consistent rendering across clients once components and global styles are in place.

Accessibility also improves when rules are built into components. Simple measures like enforcing heading order, controlling color contrast, validating ALT text, and checking link targets at build time prevent many of the mistakes that normally slip through.

When teams move away from ad-hoc design and adopt a system, they spend less time fixing errors and more time focusing on campaign goals.

Comparing two approaches side by side

A 90-day rollout plan that respects real client support

Rolling out an EDS doesn’t need to drag on for months. A three-month plan is enough to set up a solid foundation and prove the results.

Weeks 1–3: Audit and tokens

• collect examples of current emails and note every style being used (colors, font sizes, spacing, button shapes);
• translate those into a first set of tokens using the Design Tokens Community Group (DTCG) JSON format;
• pick a build tool, such as Style Dictionary, to compile those tokens into CSS that works in email.

Weeks 4–6: Core components

• build 8–12 basic components such as headings, text blocks, buttons, and simple card layouts;
• add a few variants where needed, but keep options limited;
• decide which properties marketers can edit and which should stay locked. Customer.io’s standard and custom component docs are a good reference for deciding the split.

Weeks 7–9: Structural blocks

• create the bigger repeatable pieces: header, footer, and layout shells;
• apply placement limits so, for example, the footer can’t be removed;
• add conditional display rules where supported to handle personalization without breaking layouts.

Weeks 10–12: Pilot and measure

• run a pilot with a few real campaigns;
• track how many hours it takes to build, how many review rounds are needed, final HTML size, and any rendering issues across clients;
• run accessibility checks (heading order, color contrast, ALT text) and compare against your old process;
• adjust and repeat based on the results.

By the end of three months, the system should already show savings in time and fewer rendering errors, while setting a clear baseline for future improvements.

Guardrails all teams should adopt

EDS only works if it comes with clear rules. These guardrails keep campaigns stable and save time when new people join the team.

• keep tokens in source control: Store design tokens in Git alongside your email code. Don’t leave them buried inside a design file. This way, every change is tracked just like code;
• precompile styles: Stick to inline CSS or class-based CSS that’s proven to work in Outlook, Gmail, and other major clients. Avoid runtime CSS variables, since many inboxes still don’t parse them;
• document component usage: Each component should have a simple guide with “do” and “don’t” screenshots. A short list of rules is often enough to stop mistakes before they happen;
• treat progressive features as optional: AMP content should only be an add-on, never the only version. The same goes for dark mode styling: test against support tables and always keep a solid HTML baseline;
• automate checks: Use linters to catch missing ALT text, empty links, and broken heading order. Add an accessibility test to QA; the latest EMC report shows that almost every email still ships with serious barriers.

Wrapping up

A well-built EDS removes repetitive work, reduces errors, and gives teams a faster path from idea to inbox. Whether you build it inside your ESP or through a portable module library, the goal is the same: consistent, reliable emails that scale with your business.