Why startups overcomplicate transactional email
A familiar spiral:
- “We should send a welcome email.”
- Evaluate five ESPs with enterprise PDFs
- Debate React vs MJML vs a visual builder
- Sketch a newsletter roadmap nobody asked for
- Wonder whether you need an MCP server
- Still have not sent the welcome email
This is not diligence. It is anxiety wearing a product-management hat.
The minimum stack that actually ships
- Verify a domain (SPF/DKIM)
- One API key
- One HTTPS send call
- Logs (and webhooks when bounces start to hurt)
That is enough for password resets, magic links, and receipts. Everything else is optional complexity you can buy later with evidence.
Complexity that feels like progress
These items are easy to justify in isolation and deadly in combination:
- Official SDKs for a three-field JSON body
- MCP servers wrapping
fetch - Template marketplaces for a one-off receipt
- Marketing automation “just in case”
- Multi-ESP abstractions before the first send
Each one creates meetings. Meetings feel like momentum. Inbox delivery is the only momentum that counts.
SES is a special case of overcomplication
AWS SES is great infrastructure and a mediocre first product experience. New accounts hit sandbox limits. Production access can take weeks or months. You assemble logging and webhooks yourself.
Use SES when you have AWS ops maturity and volume that cares about unit cost. Do not use “we might need SES later” as a reason to avoid sending today. Longer take: Why SES is great — and when it isn’t.
A better default for early-stage teams
- Pick a minimal transactional API
- Own your HTML (however you generate it)
- Add observability when failures matter
- Introduce marketing tools only when you actually run campaigns
If a vendor’s homepage leads with audiences, journeys, and drag-and-drop, you are shopping for a different problem than the one your users have when they click “Forgot password.”
Just send the damn email.