Verified against v0 · 2026-07-22
Build a transactional email template that survives real inboxes
A v0 brief for a React Email template built around how email clients actually render HTML — table-based layout, a fixed safe width, and a genuine plain-text fallback, not browser assumptions ported over unchanged.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Generate a transactional email template for an order-shipped notification using React Email (@react-email/components), built as a typed component that accepts props for the dynamic content — not a static template with the sample data hardcoded inside it.
CONTENT AND PROPS
Props: { customerName: string; orderNumber: string; items: { name: string; qty: number }[]; trackingUrl: string; estimatedDelivery: string }. Render every piece of dynamic content from these props — no hardcoded name, amount, or link anywhere in the template that should have come from a prop instead.
EMAIL CLIENT REALITY
Email HTML rendering is far more constrained and inconsistent than a browser — build around that reality explicitly, not around how this would look as a regular web page:
- Use React Email's own layout components (Section, Row, Column, Container) rather than CSS flexbox or grid for layout — flexbox and grid support is unreliable across major email clients including Outlook desktop, which still uses a Word-based rendering engine for HTML email.
- Inline all styles — React Email handles this automatically when you use its components as intended, but if any custom style is added outside of them, keep it inline on the element, since many email clients strip <style> blocks in the <head> entirely.
- Keep the total template width at 600px and design for that width being the maximum — email clients do not reliably respect viewport meta tags the way browsers do, so there is no real "responsive" behavior to lean on beyond a fixed, safely narrow layout.
- Include both a light-mode-safe and dark-mode-safe version of any image or logo, since a growing share of inboxes (Apple Mail, Outlook.com) apply automatic dark-mode inversion to email content in ways that can make a white-background logo turn into an unreadable dark blob — use React Email's built-in dark-mode support (React Email's built-in prefers-color-scheme media query support inside the Head component, with a dark-mode variant of the logo swapped via that query) rather than hoping it renders fine either way.
CONTENT STRUCTURE
1. A clear, specific subject-line-matching preview text (using React Email's Preview component) — this is the snippet shown in the inbox list before the email is opened, and it must not just repeat the subject line.
2. A single primary call-to-action button with generous tap-target padding, since a meaningful share of these opens happen on a phone.
3. company name, physical mailing address, and a one-line "questions? reply to this email" note — no unsubscribe link needed since this is a pure transactional shipping notice in the footer — an unsubscribe link if this is not a purely transactional message, and a plain-text company address if this is a marketing-adjacent send subject to CAN-SPAM.
FALLBACK
Generate the plain-text version alongside the HTML template — many email clients show this as an automatic fallback or use it for spam-score calculations, and a template with no plain-text counterpart, or one that's just an unformatted dump of the HTML, scores worse with spam filters than one with a genuine, readable plain-text equivalent.
CONSTRAINTS
Primary color #16A34A (green), logo already exists as a hosted PNG at a known URL — do not regenerate the logo Render the component with sample prop values as a preview so I can see it before wiring it to real data.Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
The explicit warning against flexbox and grid layout targets a real and specific rendering gap: Outlook desktop, still widely used in corporate environments, renders HTML email through a Word-based engine rather than a real browser engine, which has famously poor and inconsistent support for modern CSS layout. A model generating email markup the way it would generate a web page — because that's the vastly more common pattern in its training data — will reach for flexbox by default unless explicitly redirected to React Email's own layout primitives, which compile down to the table-based markup that email clients actually render reliably across the board.
Naming a fixed max-width and explaining why viewport-based responsiveness doesn't apply the same way addresses a category error a model can otherwise make by analogy to web design. "Make it responsive" is meaningful instruction for a webpage, but most email clients don't reliably run a full CSS engine that respects media queries or viewport units the way browsers do, so a template built with confident "responsive" web assumptions can render at a fixed, awkward width or with broken layout in exactly the clients that matter most. Stating the real constraint — design for one safe, fixed width — prevents that mismatched mental model from producing output that looks fine in a browser preview and breaks in a real inbox.
Requiring an explicit plain-text counterpart, not just an HTML template, targets something specific to how email deliverability actually works rather than a stylistic nicety. Many spam-filtering systems weight the presence and quality of a genuine plain-text alternative as one signal among several for whether a message is a legitimate transactional send or a low-effort mass mailing, so an HTML-only template — technically complete and pretty in a browser preview — can land in spam for reasons that have nothing to do with its actual content, a failure mode invisible until real send data comes back and hard to diagnose by looking at the HTML alone.
Verified against
v0 v0 by Vercel (Next.js + shadcn/ui default stack) · 2026-07-22
Changelog
- 2026-07-22 — Initial publish, verified against v0 with React Email table-based layout and a required plain-text fallback.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
