Draft transactional emails before they hit production.
A per-brand spec-and-approval workspace for the emails your product sends. Draft, version, preview, send-as-test. Link each email to the analytics events that should trigger it. NOT a campaign blast tool — that's a different category of product.
Transactional email copy lives nowhere.
Where does your product's "welcome email" actually live? Probably scattered across a Google Doc the founder drafted six months ago, a Mailchimp template someone pasted it into, a string constant in the auth controller, and the test inbox of whoever shipped it. By the time someone wants to update the copy, finding the canonical version takes longer than rewriting it.
m18t's email repository gives every transactional email a home. Slug + locale + version. Status workflow (planning → in-production). Preview that renders the HTML. Send-as-test so you can see it in your inbox before approval. Link to the analytics events that should fire it.
The canonical copy lives here. Your sender (Resend, Postmark, Mailchimp, your codebase) consumes it.
m18t does not send your emails.
m18t is a spec-and-approval workspace. It drafts, versions, previews, test-sends — then you wire the approved copy into your transactional sender (Resend / Postmark / Brevo / SendGrid / Mailchimp) or your codebase, where it gets sent at runtime to actual users. No bulk send. No drip campaigns. No subscriber-list management. Those are different products.
Capabilities
Dotted-slug naming convention
Emails are identified by slug like auth.user.confirm or billing.invoice.sent. Consistent across the platform and across your codebase.
Locale-grouped translation siblings
A welcome email in Arabic and English are linked siblings via locale_group. Edit both side-by-side; they share metadata.
Status workflow
Planning → To Do → Doing → Testing → Production. The same opinionated status set as everything else in m18t, with per-type aliases.
HTML preview with merge fields
Preview the email with sample data filled in. Catches broken markup, missing variables, and copy issues before approval.
Send-as-test
Send the rendered email to a test inbox so you can see it in real email clients (Gmail, Outlook, mobile). Catches what previews miss.
Linked to analytics events
Each email links to the events that should trigger it (welcome.email triggered by user.signup event). When team features ship, ownership lives here too.
Emails tie to events tie to controllers.
Each email links to the events that should fire it. When a developer adds the instrumentation, they read both the event registry and the email together.
Events tie back to PD controllers. So "welcome email fires from the user.signup event, which is emitted by the AuthController.create method" is one connected chain.
Each brand has its own email repository. Different brands can have completely different transactional email flows.