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

If you operate a SaaS, sending transactional email is generally a straightforward task. Numerous options exist, such as Mailgun, SendGrid, Postmark, Resend, and Amazon SES. Selecting an API or SMTP connection enables your emails to be delivered efficiently. However, the real challenge surfaced a few years ago. As the company maintains multiple SaaS products, they discovered it was difficult to answer a simple question: What emails does this application actually send?

This included not only how many emails were dispatched yesterday or which SMTP request failed, but the actual emails such as welcome emails, password resets, trial reminders, invoices, failed payments, weekly reports, invitation notifications, and reminders about inactivity.

The question then arose about who receives each email, how frequently they are sent, whether recipients are engaging with them, and whether performance is improving or deteriorating. Certain emails appear to be receiving minimal interaction. For most SaaS applications, this information is often dispersed across different locations.

Initially, with a few emails, every developer would be aware of their locations. However, as the number of emails increases—ranging from 30 to 80—the tracking becomes more complex. Different templates might be present in the application code, the email provider, or even for features that are no longer in existence. Various developers added distinct tags and metadata over time.

While the performance of an individual message can typically be examined by accessing the provider, filtering events, searching for tags, selecting a date range, and reviewing deliveries, opens, and clicks, the required overview was missing.

The team wanted a single screen displaying a consolidated view, such as: Welcome email sent 12,430 times, 71% opened; Password reset email sent 4,210 times, 82% opened; Trial ending reminder sent 980 times, 54% opened; Weekly report sent 28,110 times, 41% opened; Invite teammate sent 2,840 times, 63% opened. Moreover, the team wished to track how these numbers evolve over time.

This desire wasn't driven by the need for an additional analytics product, but rather to gain a comprehensive understanding of the communication emanating from their own applications.

Interestingly, the transactional email providers are already aware of all this data. They possess insights into the recipient, delivery status, opens, clicks, bounces, and timestamps for every email. However, the prevailing transactional email services are primarily designed for sending emails. Their fundamental unit usually represents an event or a message.

The team desired a different foundational unit—the email that their product sends. For example, "Password reset" is one email, "Weekly report" is another, and "Your trial ends tomorrow" is another. They aimed to have the template, sending history, and performance of each email in one place without the need for creating dashboards, agreeing on a complex tagging convention, or digging through millions of individual message events repeatedly. Hence, they developed Lettr.

Lettr focuses on inventorying the communication originating from your product. When an application sends a named email through Lettr, it begins building an inventory of the communication from your product. You can view all the emails that your application sends, the frequency of their dispatches, the recipients, and their performance.

Additionally, you can delve deeper into one email when necessary. Furthermore, since the email itself resides in Lettr, managing the template there becomes feasible. This design proved to be particularly significant for the team. A marketing or product person can modify the copy of an email without involving a developer to locate and alter a Blade template, make a pull request, and deploy the application changes.

However, developers retain control over the triggers for the emails and the data passed into them. The separation of responsibilities feels more harmonious to the team. The Lettr platform was built based on their personal needs. Having extensive experience in email for over 10 years, the team specialized in email infrastructure, deliverability, and email security.

However, the core idea for Lettr emerged from a more mundane problem within their own SaaS companies—they merely desired a straightforward screen displaying the emails their product sends to users and the performance of these messages. Although it may seem overly simple, they couldn't locate a tool that met their requirements. There are excellent transactional email APIs, sophisticated marketing automation tools, and detailed email analytics solutions available.

However, what was lacking was an intermediate solution—an inventory of the emails a SaaS sends, interconnected with their templates and performance metrics. This is precisely what Lettr aims to address. The team is still in the early stages of its development and is particularly keen to understand how other developers handle this aspect today.

Do they maintain a list of every email their application sends? Or, similar to their experience, would they need to sift through the codebase to uncover this information?