SES vs Firebase email extensions

The short version

Use AWS SES directly if you want:

• maximum control
• low-level email infrastructure
• direct AWS ownership
• custom sending architecture
• your own templates and rendering system
• your own bounce, complaint and suppression handling

Use EmailsDone if you want:

• SES-backed sending without the SES setup project
• built-in transactional app email templates
• simple SDK/API calls
• sender/domain setup guidance
• bounce and complaint handling built into the platform
• a safer template-first approach for common app emails
• less email infrastructure to build and maintain

The simple distinction is:

SES gives you email infrastructure.
EmailsDone gives you app email.

Quick comparison

SES is excellent infrastructure

SES is one of the best ways to send email at scale.

It is cheap, powerful and widely used. If you know what you are doing, it gives you a lot of control over how your app sends email.

That is exactly why EmailsDone uses SES underneath.

The issue is not SES itself.

The issue is that most developers do not start a new app thinking:

I can’t wait to configure DKIM, MAIL FROM, bounce notifications, suppression lists, queues and 50 transactional templates.

They think:

I need the password reset email to work.

SES gives you the engine.

EmailsDone gives you the product layer around that engine.

What you own when using SES directly

Using SES directly means you own the email integration.

That usually means thinking about:

• AWS account and IAM permissions
• SES region choice
• dev, staging and production separation
• SES sandbox vs production access
• verified sender identities
• domain verification
• DKIM records
• SPF
• DMARC
• MAIL FROM configuration
• DNS propagation
• sending limits
• API integration
• queueing
• retries
• template rendering
• responsive HTML
• bounce notifications
• complaint notifications
• suppression lists
• logs and monitoring
• operational alerts
• abuse prevention

None of these are impossible.

They are just not the thing most app developers wanted to build.

The DIY SES checklist

Sure, SES is cheap.

But before your first production email, you may need to:

• create separate dev, staging and production email environments
• implement a public email API that handles everyday traffic but can scale when your app grows
• deal with email authentication such as DKIM, SPF, DMARC and MAIL FROM
• add DNS records and wait for everything to verify
• apply for production access to escape the SES sandbox
• explain your sending use case to AWS and wait for approval
• configure domains and sending identities for each environment
• build the boring transactional emails every SaaS eventually needs
• deal with responsive HTML emails that render differently across clients
• build queueing so email failures do not break your app
• handle retries when providers fail
• process bounces and spam complaints
• build unsubscribe handling and suppression lists

That is the real comparison.

SES may be cheap per email, but the setup still costs time.

EmailsDone exists for developers who would rather spend that time building the app.

What EmailsDone adds on top of SES

EmailsDone takes the useful part of SES, reliable transactional email infrastructure, and adds the app developer layer around it.

That means:

• projects and environments
• API keys
• backend-friendly SDKs
• template-first email calls
• sender/domain setup flow
• bounce and complaint handling
• suppression awareness
• queueing
• retries
• delivery status
• common transactional templates
• prompt-first integration for coding agents

Instead of starting with a blank SES send request, you start with the app email you need.

For example:

await emailsDone
  .authentication()
  .passwordReset(resetUrl)
  .send("user@example.com");

Or:

await emailsDone
  .authentication()
  .verifyEmail(verificationUrl)
  .send("user@example.com");

Or:

await emailsDone
  .authentication()
  .welcome(actionUrl)
  .send("user@example.com");

The app still decides when the email should be sent.

EmailsDone handles the boring email layer.

SES is infrastructure. EmailsDone is app email.

This is the key difference.

SES is not trying to be your app email system. It gives you primitives for sending email.

That is valuable if you want to build your own email layer.

EmailsDone is opinionated. It assumes most app emails are common patterns:

• welcome
• verify email
• password reset
• login code
• notification
• payment failed
• trial ending
• invoice
• export ready

Most apps do not need a unique password reset design.

They need a clear, safe, production-ready password reset email that works.

That is why EmailsDone is template-first.

It trades some flexibility for speed, consistency and less maintenance.

Template ownership

With SES directly, templates are your responsibility.

You need to decide:

• where templates live
• how variables are passed
• how previews are generated
• how the HTML is rendered
• how text versions are created
• how buttons and fallback links work
• how the design behaves on mobile
• how the email looks in Gmail, Outlook, Apple Mail and mobile clients
• how every app email stays consistent

You can absolutely build this yourself.

But then you are building an email template system as well as your actual app.

With EmailsDone, common app email templates are already part of the product.

Your app passes the important data.

The template is already there.

Developer experience

A direct SES integration usually starts with AWS setup and low-level sending code.

The app has to know about the provider shape.

With EmailsDone, the app talks in app events.

For example:

await emailsDone
  .authentication()
  .loginCode("123456")
  .send("user@example.com");

That is very different from building a subject, HTML body, text body, sender, recipient, configuration set and template data for every message.

The point is not that one API call is impossible.

The point is that every app eventually collects lots of these emails, and each one becomes another small decision.

EmailsDone removes many of those decisions.

Firebase and backend integration

If you are building with Firebase, SES directly means you need to bridge Firebase and AWS yourself.

A safe setup usually means:

Frontend app
↓
Firebase Function
↓
Your SES integration
↓
Recipient inbox

That means your Firebase Function or backend code needs to deal with AWS credentials, SES calls, template data, queueing and error handling.

With EmailsDone, the shape is still safe and backend-based:

Frontend app
↓
Firebase Function
↓
EmailsDone
↓
Recipient inbox

But the function can stay focused on app logic:

• is the user authenticated?
• is App Check enforced?
• is this action allowed?
• which email should be sent?
• what URL or code does the template need?

Then EmailsDone sends the app email.

Example:

import { onCall, HttpsError } from "firebase-functions/v2/https";
import { defineSecret } from "firebase-functions/params";
import { EmailsDone } from "emailsdone";

const emailsDoneApiKey = defineSecret("EMAILSDONE_API_KEY");

export const sendWelcomeEmail = onCall(
  {
    secrets: [emailsDoneApiKey],
    enforceAppCheck: true,
  },
  async (request) => {
    if (!request.auth?.token.email) {
      throw new HttpsError("unauthenticated", "You must be signed in.");
    }

    const emailsDone = EmailsDone.fromApiKey(emailsDoneApiKey.value());

    await emailsDone
      .authentication()
      .welcome("https://app.example.com/get-started")
      .send(request.auth.token.email);

    return { queued: true };
  }
);

The backend is still yours.

The SES project is not.

Cost vs effort

SES is famously inexpensive at the infrastructure level.

That is one of its strengths.

But the cost of SES is not only the per-email price.

There is also the setup and maintenance cost:

• time spent configuring AWS
• time spent getting out of sandbox
• time spent building templates
• time spent debugging email rendering
• time spent wiring bounce and complaint handling
• time spent maintaining suppression logic
• time spent explaining all of this to a coding agent or future developer

If you already know SES well and want full control, that cost may be worth it.

If you just want app emails working, that cost may be the wrong place to spend your energy.

EmailsDone charges for the convenience layer:

SES-backed sending, without every app becoming an SES implementation project.

When to use SES directly

Use AWS SES directly if:

• you want full control over email infrastructure
• you are comfortable with AWS
• you want to build your own template system
• you need unusual sending behaviour
• you want to own bounce and complaint processing
• you have a team that can maintain the integration
• email infrastructure is important enough to build yourself

SES is a good choice when the control is worth the ownership.

When to use EmailsDone

Use EmailsDone if:

• you want transactional app emails working quickly
• you are building a Firebase, SaaS or app backend
• you do not want to write 50 HTML email templates
• you do not want to configure SMTP or raw SES details
• you want common app emails available through simple SDK calls
• you want bounce, complaint and suppression handling to be part of the platform
• you want to spend less time on email infrastructure

EmailsDone is a good choice when email is necessary, but not the product.

Final recommendation

AWS SES is excellent email infrastructure.

EmailsDone is built on that kind of infrastructure because it is the right foundation for transactional email.

But most developers do not want to build an email platform every time they build an app.

They want the app emails to work.

So the decision is simple:

Use SES directly if you want to own the email infrastructure.

Use EmailsDone if you want SES-backed app email without the SES project.

SES is the engine.

EmailsDone is the shortcut.