Why email APIs should stay small
Most email products start simple and die of feature gravity. Templates. Builders. Audiences. A/B studios. Suddenly you needed a password reset and inherited a CRM.
That is not inevitable. It is a product choice.
The job is small on purpose
App email is boring — and that is a feature:
- Password resets
- Magic links and OTPs
- Welcome / verify messages
- Receipts and invoices
- “Something happened in your account” notifications
None of that requires a newsletter suite. It requires a reliable send pipe and a way to see what happened when mail fails.
If your roadmap starts with “segmentation,” you are already building the wrong company for this customer.
Small API, honest product
Notify’s public contract is intentionally tiny: to, subject, message, optional from. Auth is one header. Observability is logs and webhooks. That is the product.
How you build the body — string template, React render, Markdown, a CMS — is your problem. An email API that tries to own your content layer is solving a different problem, usually so it can upsell a studio later.
Small APIs are easier to explain to a teammate, an LLM, and a future you who has forgotten the integration.
What “small” protects
- Time to first email. Minutes, not a platform tour.
- Pricing you can say out loud. Free / $10 / $50 without a calculator.
- Docs that fit in a sidebar. Not a second product.
- A roadmap that cannot betray transactional users by pivoting into marketing automation.
Feature gravity always pulls toward the bigger budget. Enterprise marketing clouds pay more than indie hackers sending password resets. If you do not draw a hard line, the product will.
The counter-argument
“But what if we need campaigns later?”
Then buy a marketing tool later. Do not tax every transactional send today with the architecture of a hypothetical newsletter. Most startups never become email marketers. Almost every app needs a reset email.