HTML email generator, from a builder shaped for the wrong runtime

HTML email is its own runtime

The phrase "HTML email" sounds like a mild dialect of HTML you read in a browser. It is not. It is a parallel render target with a different parser, a different layout engine, and a different set of forbidden features per client. Outlook for Windows uses Microsoft Word's rendering engine, which has no flex, no grid, no transform, and a frosty relationship with anything more recent than CSS 2.1. Gmail's web client cuts the message off at about 102 KB and strips most <style> blocks before display. Yahoo and AOL each have their own quirks. Apple Mail is the most permissive of the bunch, and even there a forced dark-mode pass can recolor your brand on you.

The shape that survives all of those is, basically, 2003 markup. A single outer table at a fixed width, nested tables for sections, inline style="..." on everything, system-font stacks, colors as hex literals, layout via padding rather than margin where possible, and one careful @media (max-width:600px) block for the phone breakpoint. That language is the lowest common denominator across thirty years of email clients. It is also exactly the language a modern frontend stack tries hard to abstract away.

Which is fine when you are using a tool built for email. Beefree, Stripo, Topol, Postcards, MJML, Mailmeteor, Unlayer, Sender: all built on this premise. They emit table-based, inline-styled HTML by default because they were designed around the constraints. A general-purpose AI app builder was not.

What email rendering actually demands

The pipeline below is what a single email goes through between sender and pixel. Every link in this chain is hostile to modern web assumptions. That is the gap an AI app builder has to clear.

What mk0r actually has under the hood

When you open mk0r and start typing, an E2B sandbox is already warm. Inside it, the project at /app exists before you arrive. It exists because docker/e2b/e2b.Dockerfile line 70 ran this command at template build time:

RUN npm create vite@latest . -- --template react-ts \
 && npm install \
 && npm install -D tailwindcss @tailwindcss/vite

So every fresh sandbox boots with a Vite + React + TypeScript + Tailwind v4 project on disk and a dev server already running on port 5173 with HMR. The agent reads two more files on first prompt: /app/CLAUDE.mdline 14 ("all new components must be imported here", pointing at src/App.tsx) and the system prompt at src/core/e2b.tsline 148, which describes the agent as "an expert app builder inside an E2B sandbox with a Vite + React + TypeScript + Tailwind CSS v4 project at /app".

Three reinforcing signals, all pointing at React. The agent does not pick the stack; the environment picks it. So when the prompt arrives, the path of least resistance is to add a component to src/App.tsx and call it done. That component might look great in a browser. It will fall apart in Outlook.

The same idea, in two languages

On the left is what the agent ships when you say "build me an order-confirmation email". It looks correct in the dev server preview because the dev server is a browser. The right side is the same content reshaped for an email client: nested tables, inline styles, fixed widths, no flex anywhere. Both render "the same email" if you squint. Only one survives Gmail and Outlook.

<!-- what the agent ships by default -->
<div className="flex items-center gap-4 p-6 bg-white rounded-xl">
  <img src="/logo.svg" className="h-10 w-10" />
  <div className="flex-1">
    <h1 className="text-2xl font-bold text-zinc-900">
      Order confirmed
    </h1>
    <p className="text-zinc-600 mt-1">
      Thanks, {firstName}. Your order is on its way.
    </p>
  </div>
  <a
    href={ctaUrl}
    className="inline-block bg-teal-500 hover:bg-teal-400
               text-white px-5 py-2.5 rounded-lg font-medium"
  >
    Track order
  </a>
</div>

The right-hand version is verbose on purpose. There is no shorthand. Every padding has to live on a <td>, every color has to be a hex literal in an inline style, every CTA button has to be a table cell with a bgcolor attribute because Outlook ignores rounded corners on links. The placeholders ({{ first_name }} and similar) are intentionally left as Liquid-style tokens so a templating engine can fill them at send time.

What each major client actually breaks on

None of this is the agent's fault when it goes wrong. The quirks below are what the email runtime imposes. The point of knowing them is that you can spell them out in the prompt, and the agent will respect each one if you do.

The override prompt that produces a real email

A prompt that gets a usable email out of a Vite-shaped sandbox does five things at once. Drop any one and the React scaffold pulls the agent back to the path of least resistance.

1. Name the output path. "Write to /app/dist/order-confirm.html, do not edit src/." The path tells the agent this artifact lives outside the React tree. Without it, the file lands next to App.tsx and you spend ten minutes finding it.
2. Forbid the modern stack out loud. "No React, no Tailwind, no flex, no grid, no @import, no external stylesheets, no script tags, no class attributes." This list is the agent's prior, written backwards. Each item cancels one of the defaults the sandbox is shaped to encourage.
3. Spell out the email shape. "Single 600px-wide outer table, role="presentation", cellpadding=0 cellspacing=0 border=0, inline every style attribute, hex colors only, system-font stacks. CTA button is a <td bgcolor> with an <a>inside." This is the email runtime, made explicit. Most of the agent's training data on HTML is web HTML, so the constraints have to be in the prompt or they get optimized away.
4. Pin the placeholders. "Use {{ first_name }} and {{ cta_url }}as literal tokens. Do not interpolate them at generation time." Without this the agent fills the tokens with example values and you get a one-off email instead of a template.
5. Force file:// verification. "After writing, open file:///app/dist/order-confirm.html in the in-VM browser, screenshot, then send a test copy to you@example.com via Resend." This bypasses the dev-server preview, which only knows about the React project. file:// is the actual artifact.

Glued together it is verbose, maybe 200 words. That is the price of crossing runtimes. Saved as a reusable starter prompt, it pays back on every email after the first.

Where the same sandbox closes the loop

Generating the HTML is half the job. The other half is sending it, tracking opens, storing the recipient list. A drag-and-drop email builder hands you the HTML; you still need to glue it into an ESP, a database, and an admin UI. The mk0r sandbox skips that step, because the same /app/CLAUDE.md that pushes the agent toward React also lists Resend and Neon as pre-provisioned services on lines 43-46:

Which means once you have order-confirm.htmlon disk, the next prompt is one sentence: "Read /app/dist/order-confirm.html, replace the placeholders with values from recipients.json, and call resend.emails.send for each row. Log every send into a Neon emails table." The agent has shell access, the env var is already set, the database is already provisioned. No accounts to create, no API keys to paste. The generate-and-send loop happens inside one box.

That generate-store-send shape is where a general AI app builder beats a dedicated email tool. The dedicated tool gives you better templates and a friendlier WYSIWYG. The general tool gives you the whole pipeline in one prompt thread.

Honest limits

For anything more complex than a transactional template, a real email-specific tool wins. Beefree, Stripo, and Postcards have template libraries in the thousands and a visual editor that knows the constraints natively. MJML lets you write structured templates in JSX-like syntax that compiles down to safe HTML. If you are sending high-volume marketing campaigns with weekly redesigns and a non-technical team, that workflow beats prompting an AI agent.

The general-builder path is best when you want one HTML email plus the send infrastructure plus a tiny admin page in the same evening, you are comfortable reading the HTML the agent produces, and the email you need is small enough to write by hand once you know the shape. Order confirmations, password resets, weekly digests for a small list, beta-invite blasts: all easy. A 12-section newsletter with seven A/B variants and a dark-mode override per section: still possible, but you will spend the time in MJML or a builder anyway.

Both paths are valid. The trap is asking a general AI app builder for an email and accepting the React component it ships first, because the dev-server preview looks correct. The override prompt above is what closes that gap. The pre-provisioned send pipeline is what makes the trade worth taking.

Frequently asked questions