We didn’t need another email API. We needed to know what our SaaS was actually sending.

Jan T — Wed, 16 Sep 2026 12:41:39 +0000

If you run a SaaS, sending transactional email is basically a solved problem.

There is Mailgun. SendGrid. Postmark. Resend. Amazon SES. And plenty of others.

Pick one, connect the API or SMTP, and your emails get delivered.

That wasn't really the problem we wanted to solve.

The problem appeared a few years later.

We run several SaaS products ourselves, and at some point we realized that answering a very simple question was surprisingly difficult:

What emails does this application actually send?

Not how many emails we sent yesterday.

Not which SMTP request failed.

But the actual emails.

Welcome email. Password reset. Trial reminder. Invoice. Failed payment. Weekly report. Someone invited you. Your export is ready. You haven't logged in for 30 days.

And then the next questions:

Who receives each of them?

How often are they sent?

Are people opening them?

Are they clicking?

Is the performance getting better or worse?

Which emails basically nobody interacts with anymore?

For most SaaS products, the answers are scattered all over the place.

Transactional email grows quietly

When a SaaS is new, this isn't a problem.

You might have five emails and every developer knows exactly where they are.

A few years later you have 30. Or 80.

Some templates are in your application code. Some are in your email provider. Some were created for an old feature that might not even exist anymore.

Different developers added different tags and metadata over the years.

If you want to understand the performance of one message, you can usually do it.

Open your provider. Filter events. Search for a tag. Pick a date range. Look at deliveries, opens and clicks.

The data is there.

What we were missing was the overview.

We wanted to open one screen and see something like:

Welcome email          12,430 sent    71% opened
Password reset          4,210 sent    82% opened
Trial ending             980 sent    54% opened
Weekly report          28,110 sent    41% opened
Invite teammate         2,840 sent    63% opened

And more importantly, we wanted to see how those numbers change over time.

Not because we wanted another analytics product.

We just wanted to understand the communication coming out of our own applications.

The weird part is that email providers know everything already

Your transactional email provider sees every email.

It knows the recipient, delivery status, opens, clicks, bounces and timestamps.

But most transactional email services are understandably built around sending email.

Their basic unit is usually an event or a message.

We wanted the basic unit to be something different:

the email your product sends.

"Password reset" is one email.

"Weekly report" is another.

"Your trial ends tomorrow" is another.

For every one of those, we wanted its template, sending history and performance in one place.

Without creating dashboards.

Without agreeing on a complicated tagging convention first.

Without repeatedly drilling through millions of individual message events.

So we built Lettr

That's the main idea behind Lettr.

It isn't really about inventing another way to send an HTTP request that results in an email.

You can already do that very well with dozens of services.

The part we cared about was everything around it.

Your application sends a named email through Lettr, and Lettr starts building an inventory of the communication coming from your product.

You can see all the emails your application sends, how many times they're being sent, who they are being sent to and how they perform.

Then you can open one of them and go deeper when you actually need to.

And because the email itself lives in Lettr, you can manage the template there too.

For us, that last part turned out to be pretty important.

A marketing or product person can change some copy without asking a developer to find a Blade template, change it, make a pull request and deploy the application.

But developers still control when the email is triggered and what data is passed into it.

That separation feels much nicer to us.

We built this because we wanted it ourselves

We've been working in email for more than 10 years.

Most of our background is around email infrastructure, deliverability and email security, so we've spent a slightly unreasonable amount of our lives looking at emails, SMTP, authentication, bounces and delivery problems.

But Lettr actually came from a much more boring problem inside our own SaaS companies.

We just wanted a screen showing us:

This is what our product says to our users.

And:

This is how those messages are doing.

It sounds almost too simple.

But we couldn't find a tool that gave us that view in the way we wanted.

There are excellent transactional email APIs.

There are excellent marketing automation tools.

There are very detailed email analytics tools.

What we were missing was something in between: a simple inventory of the emails a SaaS sends, connected directly to their templates and performance.

So that's what we're trying to build with Lettr.com (and we have acquired this nice domain!)

We're still early with it, and I'm especially interested in how other developers handle this today.

Do you actually have a list somewhere of every email your application sends?

Or, like us, would you have to search through the codebase to figure it out?

DEV Community: Jan T

We didn’t need another email API. We needed to know what our SaaS was actually sending.