Why you don’t need a visual template builder
Visual template builders promise that “anyone can edit the email.” That sounds kind. For transactional email, it is often a trap.
Transactional email is code-adjacent
A password reset needs a token your backend just generated. A receipt needs line items from your database. A magic link expires in fifteen minutes.
Those values do not live happily in a canvas disconnected from your deploy pipeline. They live next to the code that created them.
Developers already have better tools for this: components, Markdown, string templates, design systems, AI-assisted HTML. Generate the body in the app. Send the string. Review it like any other product change.
What builders actually optimize for
Visual builders shine when:
- Non-engineers iterate on marketing copy weekly
- You run brand campaigns and newsletters
- A large org needs shared asset libraries across teams
That is marketing email. It is a real job. It is not the same job as “user requested a reset.”
Collapsing both into one product creates the worst of both worlds: engineers blocked by a studio, marketers stuck in a system that cannot express dynamic product state cleanly.
The false productivity of the canvas
Builders feel fast on day one because you can drag a button. They get slow when:
- Someone needs a conditional block based on plan tier
- Localization enters the chat
- You want the email in code review next to the route that sends it
- The builder’s HTML fights your dark-mode logo or mobile layout
Transactional mail wants boring, versioned, testable content — not a second CMS.
The Notify stance
We do not ship a template studio. On purpose.
Pass message as HTML or plain text. Observe delivery. Move on.
If a stakeholder needs to tweak copy, put the strings in your repo or CMS and ship through normal review. That is how the rest of your product works. Email should not be the exception that invents a parallel product org.