One SDK for every application's transactional email, with centralized templates, abstracted providers, verified sender identities, and a log for every send.
- Year
- 2026
- Status
- Live
The problem
Every application was handling email independently.
That meant separate SMTP or provider configurations, duplicated email templates, repeated sending logic, and almost no centralized visibility into what happened after an application triggered an email.
A simple requirement like sending a welcome email could end up being implemented multiple times across different applications. When an email failed, debugging often meant going back to the application that triggered it and tracing the provider configuration manually.
I wanted email to become infrastructure instead of application-specific code.
What I built
I built Solen as an internal transactional email platform that sits between our applications and email providers.
Applications interact with a single SDK rather than knowing which provider actually delivers the message. A typical send is intentionally small:
mail.send({
template: "welcome-email",
to: "user@example.com",
variables: {
name: "Priya",
},
});Solen handles the rest.
I built the centralized template system, provider abstraction, sender identity management, delivery logging, and the dashboard used to manage and troubleshoot email activity.
The goal was to make consuming applications responsible only for saying what email they want to send, while Solen owns how that email is constructed, delivered, and observed.
Why it's shaped this way
The central architectural decision was to separate email intent from email delivery.
An application should know that it needs to send welcome-email. It should not need to know whether the message is delivered through Resend, Amazon SES, or another provider.
That separation gives us a stable internal interface while keeping the delivery layer replaceable.
It also creates a single operational boundary for email. Templates, sender identities, provider configuration, delivery status, and failures can all be managed and observed from one place.
The result is less duplicated infrastructure across applications and a much smaller surface area for application developers to maintain.
Decisions worth explaining
Provider abstraction over provider-specific integrations
I deliberately avoided exposing provider APIs directly to consuming applications.
The alternative was to let each application integrate with its preferred provider, but that would have recreated the fragmentation Solen was designed to remove.
With Solen, changing the underlying provider becomes an infrastructure decision rather than an application migration.
Centralized templates instead of templates inside applications
Email markup and content live in Solen rather than being duplicated across codebases.
This means a template can be updated centrally without having to find and modify the same email across multiple applications. It also establishes a consistent rendering and variable contract for transactional emails.
Delivery logs as a first-class feature
Sending an email successfully is not the same thing as being able to operate an email system.
Every send gets an observable outcome, including failures and provider errors. This turns debugging from "somebody didn't receive an email" into a concrete operational lookup.
Instead of asking:
Why didn't the user get the email?
we can inspect the send and see what actually happened.
What building it taught me
The biggest lesson was that infrastructure becomes valuable when it removes decisions from the systems built on top of it.
Before Solen, every application had to answer questions about providers, templates, SMTP configuration, and delivery failures. After Solen, those decisions have one home.
I also learned that abstraction is only useful when the interface represents the application's intent rather than leaking implementation details.
send a welcome email is a much more durable contract than call provider X's API with these parameters.
Most importantly, observability is part of the feature, not something added after the delivery system works. For infrastructure that other applications depend on, knowing what happened is almost as important as making it happen.
Outcome
Solen is live and is now used as the centralized email layer across our applications.
As of now, Solen has delivered over 2,000 emails with a 99.7% success rate.
It has replaced duplicated email configurations and template implementations with a shared platform and a single operational view.
More importantly, email-related failures are now traceable from one place. What previously required investigating individual applications can now be answered through a single send log.
Solen started as an internal infrastructure problem and became a small platform of its own: one interface for applications, one place for templates and configuration, and one source of truth for email delivery.