Modular Email Templates Coded for Outlook and Dark Mode

Every template here ships under 90 KB of HTML. Gmail clips a message at around 102 KB, and the part it clips takes the unsubscribe link and the tracking with it. That single limit shapes the build more than any design decision, and it is the first reason the module set is hand-coded in MJML rather than exported from a design tool. What actually gets built: Not a template. A set of modules: hero, two-up and three-up product rows, editorial block, quote block, and a footer carrying the legal identifiers a Spanish sender needs. They are compiled from MJML and then installed as saved blocks in Klaviyo universal content or Braze content blocks. After handover a marketer assembles a send from the set without opening HTML and without asking me. That is the point of the engagement. A beautiful one-off template that needs a developer per campaign is a bottleneck with good typography. Outlook: Outlook 2016 through 365 on Windows renders with Microsoft Word's engine. No flexbox, no grid, padding ignored on a div, and background images only through VML. Buttons are built as VML plus a table cell rather than as a styled anchor, because a styled anchor collapses to text width and the 44-pixel tap target disappears. Images carry explicit width and height attributes rather than CSS alone, or Word scales them to their native size and breaks the row. Dark mode, which is two problems: Apple Mail and iOS invert selectively, adjusting colours near white and near black while leaving mid-tones alone. Outlook.com and the Windows app force a full inversion of everything regardless of what the CSS asks for. So a dark logo on a transparent PNG disappears in one and survives in the other, and a white card on a white body becomes invisible in both. The colour set is chosen so that both behaviours produce something readable, and each module is checked in both before it ships. Images off: Every email is built to be read with images blocked. Real text stays as text, alt attributes are written as copy rather than as filenames, and alt text is styled with colour and size so a blocked image still reads as a heading instead of as grey Times New Roman. Accessibility: role="presentation" on every layout table, a lang attribute set to es or en, body text at 16 pixels minimum, contrast at 4.5:1 measured against the actual background rather than the intended one, single-column reflow at 600 pixels, and a heading order that makes sense read aloud. For a nonprofit whose donor base skews past 65, this is the difference between a gift and a squint. Testing runs through Litmus or Email on Acid across the client set that matters for your list, derived from your own user-agent data rather than from a generic list. What I don't build: Brand identity or art direction. I build from your design system; if there is not one, hire a designer first and I will build what they draw. No AMP for Email: it needs per-sender registration, renders in a shrinking set of clients, and always requires an HTML fallback, so the fallback is the email. No CSS accordions or carousels, which break in Outlook and hide content from screen readers. No image-only emails, even when the comp arrives that way. And not the copy. Wrong fit: A brand expecting pixel parity with a Figma comp in Outlook. It does not exist, and a build chasing it produces fragile HTML that breaks the first time someone edits a block. If the only brand typeface is a licensed web font with no email licence, understand that Gmail and Outlook show the fallback stack, so the fallback is the real design for a large share of your list and it gets designed on purpose rather than by accident. Handover: MJML source in a repository you own, compiled HTML, the installed block set in your platform, and a one-page rule sheet for whoever builds sends after me.