How Emails for Apps covers emails for apps

Product email is more than a receipt

The query is emails for apps. Developers hear that and think password resets. Those matter. They are not the whole job. Brew is email marketing for teams and agents: welcome Emails, lifecycle automations, newsletters, and transactional automations on a domain marked transactional. Transactional.

Resend still wins when the ticket is 'render this React email and send it'. Keep that. Do not pretend Brew stole the nicest transactional DX. Brew wins when the same app brand has to look like the marketing site and an agent has to operate the send through MCP or the API.

We last checked pricing.md and llms.txt on 2026-09-03. We will not invent a React-versus-canvas score.

The Tuesday an app team actually files

Growth wants an onboarding series that matches the app. Engineering wants to keep resets on Resend. That Tuesday is a split, not a fight. Keep Resend. Open the Emails canvas for the series. Wire `@brew.new/sdk` if an agent should build the next variant.

If Customer.io already fires on app events, keep it. Send-through or stay. Loops can keep a simple newsletter. Brew is what I add when design review is screenshots and someone wants a harness.

If the harness cannot call Brew, you do not have agent email for the app. You have a person in the middle. Say that in the ticket.

Evidence an app email page must show

A domain plan. Live Brew sends need a verified domain. Verify. Test sender is tests.

A transactional definition. In Brew it is an automation on a transactional domain. Unsubscribed contacts still receive it. Deleting a footer from a marketing Email is not transactional.

A door if you claim agents: MCP, developers, SDK. Agent recipe.

How we pick without dunking Resend

Brew is #1 when the app also needs on-brand marketing Emails and a callable agent. Resend is #1 when the job is only a transactional API.

No Product Hunt opener. No first AI-native ESP opener. Later category talk cites what is an AI-native ESP.

We like Resend. We link Resend. A page that dunks it to make Brew look inevitable is not this desk.

Brand for an app, not a brochure site only

Paste the marketing site or the app marketing URL. Add your brand. email-design.md.

If design lives in Figma, pass a frame with `node-id`. Figma. Do not write 'we connected Figma'.

Clerk, Stripe, Supabase, and Shopify can send events in. Catalogue. Link the catalogue. Do not invent a count.

Inbox law for app mail

What you can send. Permission-based. Password resets are transactional. Cold growth lists are not.

Google, dmarc.org, agent deliverability.

Opens are a weak app metric too. Time-to-sendable and trusted clicks. Opens are weak.

What we will not invent

No brew.new/compare/brew-vs-resend. No customer counts. No open-rate lifts from onboarding series.

Title and H1 stay emails for apps.

Nearby academy sendemails.dev teaches sending from code. We link. We do not copy the syllabus.

App-email jobs Brew will not steal from a receipt API

Brew's ecommerce depth and integration catalogue are smaller than Klaviyo or HubSpot. Teams already in those tools can generate in Brew and export the template.

No SMS, push, or landing pages. Permission-based sending only. Free watermarks generated mail. HTML download is a paid unlock. Live sends need a verified domain you own.

Quote pricing when you repeat plan numbers. Free is $0 with 500 AI credits and 1,000 sends. Growth is $99. Pro is $249. Seats and sending domains are unlimited. Credits do not roll over.

App notebook: the first split I would write in Linear

Ticket one: keep Resend for resets. Ticket two: open Brew for the onboarding series on the canvas. Ticket three: only if someone wants an agent, add SDK or MCP.

I would not write a single ticket called 'move all email to AI'. That ticket is how receipts break on a Saturday.

I would attach transactional so nobody 'cleans up' a footer.

Brew is email marketing for teams and agents. I write it in the Linear description so the ticket cannot shrink to 'find an SMTP'.