Manu came to Mate & Build with no expectations. Her team took days to create a marketing email — from the idea to the final HTML ready for Braze, given the day-to-day pace and the number of countries involved. Three hours later, they were doing it in 10 minutes. This is what we built, why we built it this way, and what broke along the way.
"Building one email takes days and goes through 3 teams"
Manuela Fernández del Tejo works as Fintech Marketing Strategist at PedidosYa, handling brand, content and media. Her pain was concrete: creating a marketing email for Braze required coordinating content, design and HTML production — a pipeline that consumed days going back and forth between different areas.
She came to Mate & Build — the weekly AI problem-solving sessions Patricio Iturraspe runs — with 3 problems. One was too complex for 3 hours. We focused on the 2 that shared the same axis: email creation in Braze.
What she told me when she sat down was honest: she had zero faith in this. Zero expectation.
The whole pipeline was the problem, not the writing
When we sat down to break the process apart step by step, the thing the day-to-day rhythm never lets you see showed up. It wasn't just writing the content. It was thinking about the structure, writing for multiple segments with Braze's dynamic variables, converting everything to production-ready HTML compatible with Outlook, Gmail and Apple Mail — with MSO conditionals, VML for buttons, responsive design — and loading everything with the right custom attributes.
Each piece of that process lived inside a different person or team. That's where the time was going.
The question stopped being "how do we automate the writing" and became "how do we build a system that covers the full pipeline and improves on its own with use."
Why 2 separate skills and not a monolithic pipeline
The most important design decision was separating responsibilities. We could have built a single skill that takes a brief and spits out HTML. We chose not to for a practical reason: when something fails inside a monolith, you don't know where it broke.
Two skills in Claude Code and one permanent reference file.
email-drafter writes the content in structured plain text — HERO + BODY + CTA. Supports multiple segments and Braze dynamic variables. Clean output: just what the email says, no HTML, no design.
email-to-html takes that plain text and turns it into production-ready HTML. Tables for layout, inline styles, MSO conditionals for Outlook, VML for CTA buttons, responsive with media queries. The structure has 10 rows: logo, hero with mobile/desktop versions, body, tagline, cards, closing, help and footer.
html-structure-reference isn't a skill — it's a permanent reference file. It documents the HTML structure as patterns (~3k tokens) instead of pasting real production HTMLs (~10–15k tokens). Both skills consult it as the source of truth for colors, assets and specs of each component.
If the content is right but the HTML comes out wrong, you only touch skill 2. If you add a new segment, you only touch skill 1. You don't break what already works.
7 failed iterations were the most valuable part
Here comes the part nobody tells.
The first iterations didn't work. Braze custom attributes were getting mapped wrong, the HTML came out broken, the structure didn't respect the specs. It took almost 7 iterations to get a production-ready email. Each one taught something the previous ones couldn't show.
And the most revealing mistake: at first we gave it the reference template as a PDF. It seemed logical — that's the format the team had it in. But Claude Code couldn't parse the structure well from a PDF. The styles got lost, the row hierarchy got confused, the components couldn't be distinguished.
It was only when we gave it real HTML templates as reference that the output quality jumped sharply. The lesson is a pattern that applies to any skill: the quality of what you give it as reference exponentially defines the quality of what comes out. A PDF "looks like" the final result but doesn't have the structural information the system needs. An HTML has the full truth.
"I really can't believe it. I was honestly surprised. I thought it was going to solve 80% of it, but the truth is it solved 98%. Incredible." — Manu
Why we chose for the system to learn on its own
What really set this build apart from a regular automation were the self-modifying prompts. We could have delivered 2 skills and a static reference file that work well today. We chose to add the learning layer because the real value isn't in solving today's problem — it's in the system solving tomorrow's problems better.
Three files do the work: prompts that modify themselves, lessons that accumulate, and persistent memory. Every time a skill generates an email and there's an error — a dynamic field mapped wrong, a style that doesn't render, a structure that breaks in Outlook — the system saves it as a lesson. The next time it runs, it consults those lessons before generating.
It doesn't make the same mistake twice.
The system Manu took home yesterday isn't the same one she'll have a month from now. It'll be better. Every email it generates trains it. Every correction the team makes turns into permanent knowledge.
From days to 10 minutes — and what's left
Without the system: idea for the email, drafting with the content team, design, HTML production, Braze upload with custom attributes. Days.
With the system: idea for the email, email-drafter (2 min), email-to-html (3 min), quick review, Braze upload. 10 minutes.
And the quality goes up because each skill works with precise specs, not interpretations of a brief. The html-structure-reference is the source of truth that removes the ambiguity between what content asked for and what dev interpreted.
The third problem Manu brought — the most complex — stayed out of scope. It's the natural next step. There's also room to iterate: more reference templates, more accumulated lessons, and eventually wiring the output directly to the Braze API to remove the manual upload step.
But that's optimization. What she has today already changed the game.
Takeaways
- Separate responsibilities > monolith: 2 skills + 1 reference file where each piece does one thing well.
- Reference in the final format, always: a PDF "looks like" the result but an HTML has the structural truth.
- Self-modifying prompts turn tools into systems: lessons and memory turn every error into a permanent improvement.
- Iterating isn't failing: 7 iterations to production-ready.
- The biggest value is replicability: Manu took home the structure for her team at PedidosYa to create new skills following the same pattern.
Concepts applied here
- File system for AI (in Spanish) — 2 skills + reference file instead of a monolithic mega-prompt.
- Context engineering (in Spanish) — self-modifying prompts and persistent memory that improve the system with every use.
- AI for marketing (in Spanish) — how a marketing team at a LATAM company builds its own system without depending on IT.