Changing a mail template used to need a deploy. We built an editor that refuses to publish a broken one

Description and use

The new template system lets non‑developers edit transactional emails and PDFs without code deployments, validating required variables and blocking broken publishes.

Problem

Non‑developers could not edit transactional mail or PDF templates without a code deploy, leading to operational bottlenecks and risk of broken content.

Outcome

The new unified template system allows non‑developers to edit transactional mail and PDFs without code deployments, enforces required placeholders, and prevents publishing broken content.

Workflow

• Identify duplicate mail systems and lack of unified template model.
• Design a single template model with slug, locale, document, and meta.
• Implement structured document editing with tiptap and server‑side sanitization.
• Create separate layout templates for mail (MJML) and PDF (letterhead).
• Add required placeholder validation and publish blocking in the editor and server.
• Separate draft and active template storage to prevent accidental overrides.
• Implement PDF rendering via Puppeteer with real preview and metadata.
• Deploy the unified editor and preview system.
• Document the workflow for non‑developers to edit templates safely.

Evidence

Changing the wording of a password‑reset mail in our framework meant editing a TypeScript file and shipping a release.

Source

The mail editor has the placeholder rail on the left with type, required marker and a check for whether the placeholder is used.

Source

That rule is enforced on the server and not only in the editor. Saving rejects unknown placeholders.

Source

PDFs use the same document model, rendered through Puppeteer in a separate service that runs Chromium behind an egress guard.

Source