How a marketer and a developer work on the same email

A marketer changes a headline after an email has already been built. The developer updates the layout, but before the new version is approved, another stakeholder asks for a different CTA and legal sends an updated disclaimer. Soon, several files are circulating between team members, screenshots appear in chats, and nobody is entirely sure which version should be considered final.

This is a common email design problem, but the real issue is not that marketers and developers cannot work together. More often, the production model forces too many routine tasks to move back and forth between them. A better approach is to divide the work according to what each person creates: the developer builds the technical system, while the marketer uses that system to assemble and update campaigns.

The principle is simple: no-code by default, HTML when you need it.

Why the traditional workflow creates unnecessary delays

In many teams, email production still follows the same pattern. The marketer prepares the content, sends it to a developer, waits for the email to be assembled, reviews the result, requests corrections, and then waits for another version. The same cycle repeats whenever someone changes the offer, adjusts the wording, replaces an image, or updates the footer.

Most of these changes are not technical. If a discount changes from 15% to 20%, a headline becomes longer, or a product manager replaces one feature with another, there is usually no reason for the developer to rebuild the email. Yet in a rigid workflow, the marketer still has to send the request and wait for someone else to make a relatively simple change.

The second problem is version confusion. Feedback often arrives through several channels at once:

• Copy corrections in a shared document;
• Comments in Slack or another messenger;
• Screenshots with arrows and notes;
• Updated HTML files sent by email;
• Verbal feedback from meetings.

This is how teams end up with files called campaign_final.html, campaign_final_v2.html, and campaign_final_approved_NEW.html. The problem is not a lack of effort. It is the absence of a clear system for ownership, editing, and review.

Divide responsibilities by what each person creates

A developer should not have to build every campaign from scratch. Their main contribution is creating the technical environment in which future campaigns can be produced safely and efficiently. This means defining reusable structures, setting responsive behavior, solving compatibility issues, and handling the tasks that genuinely require code.

The marketer works on a different level of the same system. Marketing owns the message, content, CTA, images, links, offers, and routine adjustments that happen before a campaign is sent. Once these responsibilities are clearly separated, developers can focus on technical work while marketers are not forced to wait for every content update.

A practical division of responsibilities might look like this.

The developer owns:

• Reusable modules and structural blocks;
• Technical behavior and responsiveness;
• Compatibility issues that require technical expertise;
• Custom interactive elements;
• Client-specific technical requirements;
• Code that cannot be handled safely within a no-code workflow.

The marketer owns:

• Campaign copy and messaging;
• Images, links, buttons, and offers;
• Content order and block selection;
• Routine spacing and visual adjustments;
• Final campaign assembly;
• Review, approval, and export to the ESP.

This relationship is intentionally asymmetric. The developer is heavily involved at the beginning, when the system is created, but becomes much less involved in routine production. Once the foundation is ready, the marketer can work independently and bring the developer back only when a task actually requires technical expertise.

Developers create the module library once

A strong email template design system begins with reusable modules instead of a collection of one-off templates. The developer can create a library of approved components for the most common campaign scenarios, allowing the marketing team to reuse reliable structures instead of rebuilding similar sections every time.

A typical module library may include:

• Headers and navigation blocks;
• Hero sections;
• Image-and-text combinations;
• Product cards;
• CTA sections;
• Promotional banners;
• Article previews;
• Testimonial blocks;
• Social media sections;
• Legal information;
• Footers.

Each component can already contain the core visual and technical rules required by the brand. A product card, for example, may have predetermined image proportions, headline styles, CTA placement, spacing, and mobile behavior. Once that module has been tested and approved, the marketer does not need to ask a developer to create another product card every time a new product is promoted.

This is the practical value of modular email design. Instead of treating each email as a separate technical project, the team creates a reusable design system that supports many future campaigns.

A module library also protects visual consistency. When every campaign begins with a blank canvas, small differences quickly appear. Button padding changes, headings use slightly different sizes, image proportions vary, and old footers may be copied into new campaigns. Reusable modules reduce these inconsistencies because the most important design decisions are already built into the blocks.

Author: Walls.io

The marketer can build campaigns without code

Once the reusable foundation exists, most daily campaign production can move to the marketing team. A no-code email template builder allows marketers to combine approved elements without working directly with HTML every time they need to launch a promotion or newsletter.

The marketer can independently handle tasks such as:

• Replacing copy and images;
• Changing buttons and URLs;
• Rearranging content sections;
• Adjusting spacing;
• Working with approved fonts;
• Checking mobile responsiveness;
• Reviewing dark-mode behavior;
• Updating the footer;
• Preparing the final email for export to an ESP.

These are everyday marketing tasks and should not automatically create a development request. Campaigns often change shortly before launch. A price may be updated, an event may sell out, a product image may need to be replaced, or a stakeholder may ask for a stronger CTA only a few hours before the scheduled send.

When marketers can make these changes themselves within an approved system, the campaign stays flexible without putting the technical quality of the email at risk. The developer has already created the boundaries, and the marketer can work confidently inside them.

A practical workflow for email production

A clear process based on email design best practices can be represented as a simple sequence:

Brief → Layout → Module library → Marketer assembly → Review → Final

Each stage has a specific purpose and prevents routine changes from sending the project back and forth between different team members.

1. Brief

The marketer defines the campaign goal, audience, main message, CTA, and content requirements. At this stage, the conversation should focus on what the email needs to communicate rather than how it will be coded.

2. Layout

The visual structure is planned. The team decides what recipients should notice first, how content should be grouped, how much information belongs in each section, and how the campaign should reflect the visual identity of the brand.

3. Module library

The developer creates or approves the reusable structures needed for the campaign. Technical questions such as responsive behavior and compatibility are addressed here so they do not have to be solved again in every individual email.

4. Marketer assembly

The marketer combines existing modules, replaces the content, updates links and images, changes the order of the sections, and prepares the campaign for review. Routine edits remain within the marketing workflow rather than becoming development tasks.

5. Review

The team reviews the actual email for copy, visual hierarchy, links, layout, responsive behavior, legal information, and final campaign details. Feedback should relate to the current working version rather than to disconnected screenshots or outdated files.

6. Final

Once comments are resolved, the approved version becomes the final version for testing and export. The important point is that the workflow moves forward instead of repeatedly returning to development because of small content changes.

[Diagram suggestion: Brief → Layout → Module Library → Marketer Assembly → Review → Final]

Collaboration should happen around the actual email

Reusable modules solve the production problem, but teams also need a reliable way to manage feedback. Even a good production system becomes inefficient when one person comments in a messenger, another sends corrections by email, and a third annotates a screenshot that may already be outdated.

This is where email design software can improve collaboration. Instead of sending a screenshot and writing “change this button,” reviewers should be able to leave feedback in the context of the actual email. If someone wants to restore an earlier headline or compare two versions, the team should be able to check the version history rather than search through old attachments.

For effective collaboration, a shared environment should support at least three things:

• Comments connected to specific blocks or elements;
• Collaborative editing of the same email;
• Version history that shows what changed and allows previous decisions to be reviewed.

Stripo supports collaboration on the same email, comments connected to email elements, reusable modules, and version history. The practical benefit is that marketers, designers, developers, and reviewers can work around the same campaign rather than creating several competing versions.

This also makes approval easier. Marketing can review the message, design can check visual consistency, legal can verify wording, and a developer can inspect a specific technical component if necessary. Everyone works with the same email, but not everyone has to be involved in every task.

A modular system improves more than speed

The main advantage of this model is not simply faster production. It changes how both roles use their time. Without reusable components, developers repeatedly solve small layout problems that may already have been solved in previous campaigns. With a modular system, they solve those structural problems once and make the solution available for future emails.

At the same time, marketers gain the freedom to make ordinary campaign changes without waiting for development. A late copy update, a new image, or a modified CTA remains a marketing task rather than becoming another handoff.

The same approach improves visual consistency. When approved spacing, typography, buttons, image proportions, and responsive behavior are built into reusable modules, campaigns are less likely to drift away from the brand’s visual system. Marketers still have room to change the order of the sections, choose different content, and adapt the message to different audiences, but that flexibility exists within a reliable framework.

This becomes especially valuable as email volume grows. A team that sends newsletters, product announcements, event campaigns, promotional messages, and lifecycle emails needs a scalable system rather than a new technical process for every send.

Where an HTML email template still matters

No-code should be the standard workflow, but it should not become a technical limitation. There are still situations in which an HTML email template requires direct development work, especially when the campaign contains functionality that falls outside the team’s normal module library.

A developer may need to step in for:

• A custom interactive block;
• A nonstandard AMP element;
• Unusual client-specific requirements;
• Technical behavior that cannot be handled by the existing module library.

These situations are real, but they are relatively rare compared with ordinary newsletters, promotions, product announcements, and lifecycle campaigns. Most emails do not need custom development. They need strong content, clear hierarchy, responsive layouts, reliable reusable blocks, and an efficient approval process.

HTML when you actually need it

Some edge cases will always require direct email HTML code. If a campaign needs a custom interactive element or an unusual AMP implementation, the developer can create and test it. If the element is likely to be used again, it can then become another reusable component in the team’s module library.

That is a much more efficient use of development time than asking a developer to change copy, replace an image, or adjust routine campaign content. Technical expertise remains available, but it is used where it creates real value rather than becoming a required step in every email.

The better working principle is therefore straightforward: no-code by default, HTML when you need it.

A marketer and a developer can work on the same email without both being involved in every edit. The developer creates the technical framework and reusable system, while the marketer uses that system to build, update, review, and prepare campaigns independently. With clear responsibilities, reusable modules, and a shared review process, collaboration becomes less about passing files back and forth and more about allowing each role to contribute where its expertise matters most.