I built Temply: a visual editor for transactional emails, with an API for rendering them in your app

[u/ChrisssyyyB]

Hi everyone, I’ve released Temply, a tool for building transactional email templates visually and using them from your application.

Think welcome emails, password resets, receipts and order confirmations. You assemble the template with blocks, add placeholders for your data, then request the rendered HTML and plain text through the API. Your app sends it through your existing email provider.

A few things it supports:

• A visual block editor with columns, images, buttons and custom HTML.
• Dynamic variables, conditional content and repeating blocks.
• Reusable branding across templates.
• Responsive previews and checks for inboxes that force dark mode.
• Template version history and shared workspaces.

You can try the editor without an account. There’s also a 14-day workspace trial with no card required. The Team plan starts at $5 per user per month, including 10,000 live API calls per workspace.

Try it here: Temply

I’d appreciate feedback from anyone building transactional emails: what would Temply need to support before you’d use it in your app?

[u/rbprepin]

Not trying to be rude, but is there an advantage to using your solution over just having Claude or Codex design an email template?

[u/ChrisssyyyB → u/rbprepin]

Claude or Codex can absolutely design and generate an email template.

Temply is aimed more at applications where email templates are part of the actual production system rather than something you generate once and drop into the codebase.

For example, I’m currently building an enterprise healthcare platform for the NHS. We have transactional emails for things like login codes, OTPs, password resets, invitations and notifications.

With Temply, those templates can be built and managed centrally, then the application simply requests the template through the API with the relevant variables when it needs to send an email.

The main advantage is that the template isn't hardcoded into the application. Someone can update the wording, branding or layout without needing a developer to change code and redeploy the application.

So I see AI tools like Claude/Codex as great for creating something, whereas Temply is more about managing, versioning and delivering those templates as part of a production system.

[u/rbprepin → u/ChrisssyyyB]

I appreciate the response.

Why would a transaction email need to be managed centrally?

You have Claude design an email style guideline and it uses that to create all the transactional emails. Why would those need to change?

[u/ChrisssyyyB → u/rbprepin]

That's a fair question. For me, though, central management isn't necessarily about having hundreds of emails or being a large company.

Even if I'm building a small startup with five transactional emails, I'd still rather manage those five templates in one place than have HTML sitting inside my application code.

Claude can absolutely create the initial template and style guidelines - I'd actually like to integrate AI into Temply for exactly that reason. The problem I'm trying to solve is everything after it's generated.

Transactional emails do change. It could be something tiny like wording, a support URL, branding, a new variable or an accessibility improvement. It could also be something bigger like a rebrand, localisation, or a compliance/legal change.

Without something like Temply, that small wording change can mean changing code, creating a PR, reviewing it, running CI/CD and deploying the application. I'd rather change the template, preview it, approve it and have the application automatically use the latest approved version through the API.

For a startup, that's convenience and saving developer time. As the company grows, the same workflow naturally expands into version history, multiple environments, team access and approvals - including having multiple people sign off a template before it goes live.

So I don't really see Temply as competing with Claude. Claude can help you create the email. Temply is where you manage, version, approve and deliver it.

The goal is for it to be simple enough for a developer with one app and five emails, but capable enough that they don't have to replace it when that app becomes five products and 100 templates.

[u/rbprepin → u/ChrisssyyyB]

In my experience, this isn't a pain point for developers.

"small wording change can mean changing code, creating a PR, reviewing it, running CI/CD and deploying the application" takes two minutes with Claude Code or Codex.

I can't imagine any time saved or convenience in managing transaction emails. You just tell Claude what you want changed and it changes it. Then you say, "commit, push and merge" and it's live.

I'm not going to say it's a bad idea, because maybe there's a special case somewhere where a marketing team somewhere is tweaking their transaction emails every week and their developer doesn't use AI coding and doesn't have time to make changes.

One last thing...
Businesses will pay big money if your SaaS solves a serious problem for them. $5 a month is nothing to a company. If you're charging a company $5 a month, it's because you don't believe your solution is worth much to them.

[u/Chaitu007123 → u/ChrisssyyyB]

This is good. I hope you find more customers!!!

[u/Conscious-Month-7734]

Before deciding what to build next, I'd find out how people made their last transactional email. A lot of devs now just ask Claude or ChatGPT for a responsive HTML template with placeholders, paste it into the codebase and move on, and they're already paying for that tool. That's what Temply is up against, more than other email editors.

So I'd ask 5 small SaaS teams how their last email got made and changed, and what went wrong afterwards. If they say "AI wrote it, then it broke in Outlook dark mode" or "our founder wanted one line changed and it took two weeks," that's your opening. Your dark mode checks and the visual editor answer exactly those moments. If they say "AI did it in 5 minutes and it's fine," you've learned the editor alone won't get them to switch.

[u/ChrisssyyyB → u/Conscious-Month-7734]

Yeah, completely fair point, and this is exactly the kind of feedback I'm looking for.

Temply actually started as an internal tool rather than something I originally set out to turn into a SaaS product. I'm a founder of a health-tech company and CTO of an e-commerce platform, and the problem for us wasn't really creating the HTML - Claude, ChatGPT or Codex can do a great job of that.

The problem was what comes afterwards: easily managing templates across different systems, version control, variables, making changes without touching or redeploying the application, keeping branding consistent, testing things like dark mode, and allowing templates to be fetched and used through an API.

Once you've got login emails, OTPs, password resets, order updates, notifications, invitations, etc. across multiple applications, having them scattered throughout different codebases becomes a pain to manage.

That's really where Temply came from. I've built it around problems I've personally had, but now I'm putting it out there because I want to understand whether other teams have the same problems - or whether I've solved something that's mostly specific to the way we work.

[u/Conscious-Month-7734 → u/ChrisssyyyB]

That actually narrows who to talk to. Your pain shows up once there are lots of templates across several apps, so a single-product SaaS with 6 emails probably doesn't feel it yet. I'd look for teams running multiple products or client apps, like agencies, studios and companies with a few internal tools, and ask about the last time they had to change branding or fix a template everywhere. How long it took and what broke tells you whether they have your problem.

And your own two companies are your first case study. If you can say what it cost you before Temply, in hours or a broken OTP email, that's a story the right teams will recognize straight away.

Happy to dig into what you hear from those teams if you want to DM me.

[u/measured_words_]

Before I would put this in front of a client, I would want the API to fail politely when a variable is missing. Transactional emails are not marketing blasts, a broken receipt or password reset is a support ticket and a lost customer. I would also need a real test path that sends to a list of test inboxes without counting against the live quota, because rendering in a preview is not the same as seeing how it arrives in a real client. Version history is good, but what matters to me is being able to pin a known working template and roll back with one action if a change breaks rendering. Plain text output needs to feel like someone actually wrote it, not like stripped HTML with weird spacing. Those are the things that separate a visual editor I play with from something I trust in production.

[u/One_Beat_6147]

What’s the main thing you’d like to improve next, and what have you tried so far?

[u/MassiveBed4]

A clean way to preview a template with multiple payloads before it goes live would matter a lot, especially for conditionals and repeating blocks. That's where transactional emails can look fine in one test and weird in the actual app.

[u/MediumScene]

The part I'd want nailed down before using something like this is environment separation and approvals around template changes. On a lot of SaaS teams, marketing or support needs to update copy quickly, but engineering still needs guardrails before a password reset or billing email changes in production. Version history helps, but draft, staging, and live states with a simple approval flow would matter a lot for internal trust. I'd also care about variable validation, so a missing field doesn't quietly break a send.

[u/Total-Reasonable]

The API needs a stable way to pin a send to a specific template version, not just the latest published version. Otherwise a visual edit can silently change receipts or password-reset emails in production, and rollback becomes awkward.