I've been hand-coding email templates for over two decades. I know where the bodies are buried — the Outlook VML hacks, the Gmail dark mode quirks, the padding that behaves differently on every client, the accessibility traps that are invisible until someone using a screen reader hits them. That knowledge took years to build, and it lives in every template I write.
My whole philosophy around email production comes back to mise en place — the culinary principle of having everything prepped, named, and in its place before the actual work begins. In a kitchen, that means your ingredients are measured, your tools are laid out, and nothing is improvised mid-service. In email development, it means your template system is so well-built that everyone — developers, marketers, campaign managers — can work from it confidently without things falling apart.
What's changed recently isn't the philosophy. It's how fast I can execute on it.
A few months ago I started using Claude Code alongside Denada as a core part of how I build and deliver email template systems. It's changed what I'm able to promise clients — not just in terms of speed, but in terms of depth and quality. This post is about what that actually looks like in practice.
There's a meaningful difference between a well-coded email template and a well-built email system. A template is something a developer works with. A system is something a whole team works with — marketers, copywriters, campaign managers, people who have never opened a code editor in their lives.
Turning a template into a system means exposing every editable field in a way that's obvious and foolproof. It means making sure a brand color change cascades correctly through every module without someone hunting through inline styles. It means writing documentation that an AI can understand and act on, not just a human. It means naming parameters consistently, removing Boolean on/off toggles that create confusion, and making sure empty fields simply disappear rather than leaving awkward whitespace.
That work is invisible to clients. They never see it. But it's the difference between a system that gets used exactly as intended and one that quietly breaks down the moment a developer isn't in the room.
Historically, that setup work was also slow — slow enough that I'd sometimes have to make pragmatic compromises about how thorough I could be within a given budget. Not anymore.
The setup is straightforward once you've done it once. Inside Denada, your master library has a connection string — a prompt that packages all of Denada's platform documentation, syntax rules, and constraints into something Claude can read and act on. You copy that, grab your API token from Denada, paste both into Claude Code, point it at a local working folder on your machine (not iCloud — local, to avoid caching issues), and from that point on you're just talking to a developer who has read every line of your codebase and knows Denada's rendering engine inside out.
Claude downloads your library, ingests the documentation, and gets to work. The first pass is usually a review — and it finds things. Duplicate class names. Inconsistent parameter naming. A missing font weight property. Vertical alignment quirks. The kind of low-level bugs that are genuinely hard to spot in a long hand-coded file and easy to miss in QA because they only surface under specific conditions. On the first library I ran through this process, it flagged 23 issues. All real. All fixed in the same session.
Then the real work begins.
Once Claude has the library downloaded and the documentation loaded, it works like a senior developer who takes on the style of your code rather than imposing its own. My comment structure stays intact. My naming conventions stay intact. My preference for bottom-only padding, my dark mode image swap pattern, my approach to Outlook VML — all of it. It's not rewriting your work. It's optimizing it.
Here's a sample of the kinds of instructions I give it:
Simplifying parameters: "Remove Boolean on/off parameters wherever possible and replace them with empty-field logic. If a field is empty, Denada won't render it — we don't need a toggle." This alone dramatically cleans up the editing interface for non-developer users.
Building theme logic: "I want one brand color parameter to control background color, text color, and CTA color across the module. Define the relationships so switching from Turquoise to Blush updates everything at once." This is the kind of work that used to take hours of careful find-and-replace. Claude does it in minutes.
Adding editable parameters: "Expose padding, font size, and line height as editable fields on the hero module with sensible defaults."
Normalizing inconsistencies: "Audit the library for any parameter naming inconsistencies and standardize them."
Building out new modules: "Using the coding style and parameter conventions in this library, create a 3-column icon + text module."
Every change gets pushed directly to Denada via the API. No manual uploading. You go to Denada, check what it built, and come back with the next instruction. Denada's version control means every change is a new version you can roll back to instantly — which means you can ask for ambitious things without the anxiety of breaking something irreversible.
Always pick a local folder, not iCloud. When Claude Code sets up its working directory, keep it on your local machine. iCloud syncing introduces caching behavior that causes confusing mismatches between what Claude thinks the library contains and what's actually there.
If you make manual edits in Denada mid-session, re-download before continuing. Claude is working from the version it downloaded at the start of the session. If you go in and manually tweak something, ask it to pull the library again before giving new instructions — otherwise it's reasoning from stale data.
Documentation written for AI is different from documentation written for humans. This sounds obvious but it took me a couple of sessions to internalize. When you write the chat instructions and formatting prompts for your Denada modules, precision matters more than elegance. What a developer colleague infers from context, Claude needs stated explicitly. The more specific your instructions, the better the output.
New sessions for new topics. When you're shifting from one kind of task to another — say, from cleaning up parameter naming to building a new module — starting a fresh session keeps Claude's context clean and the output sharper.
Version everything deliberately. Get into the habit of naming your library versions as you go. "V2 — Boolean parameters removed" tells you exactly what changed and makes rollback decisions straightforward.
The practical outcome for clients is that they get a deeper, more thoroughly built system than would have been possible at the same budget before. Every parameter named and exposed. Every module documented. Theme logic that makes brand color switching effortless. A library that's been audited for bugs before it ever goes into production.
That's mise en place at the system level — everything in its place before the team ever touches it. And because the whole system lives in Denada, their team — marketers, campaign managers, anyone — can work in it without a developer in the loop for every campaign. That's the point. Build the system right once. Then get out of the way and let the team use it.
If you're an email developer sitting on a solid hand-coded template system and you haven't tried this yet, set aside a few hours and run your next client library through it. The learning curve is short. The output is genuinely better. And you'll have capacity for the work that actually requires your expertise.
💬 Want to talk through the workflow? I'm happy to go deeper.
📩 Connect on LinkedIn or get in touch.
