Loops vs Resend

The ownership decision comes before the feature checklist

Loops and Resend can both appear in the same SaaS architecture, but they start from different owners. Loops starts with the team that plans lifecycle communication: a marketer, growth lead or product marketer defines an audience, writes a campaign and connects it to product state. Resend starts with the team that owns the application: an engineer renders a template, sends a message and records delivery events next to the product’s other infrastructure. The right choice depends on which person needs to move quickly every week.

A marketer-owned program needs a visible contact model. Trial users, paid administrators, invited teammates, dormant workspaces and customers who have opted out should be understandable without reading application code. Loops is a better center for that work because campaigns, contact properties and lifecycle programs share a workspace. Engineering still supplies reliable events, but a copy revision or segment adjustment does not have to wait for a deploy. '} />

An engineer-owned program needs predictable primitives. A receipt should be rendered from a versioned component, queued after a billing event, sent with an idempotency key and reconciled when a webhook arrives. Resend is a better center for that work because its API, SDKs, React Email templates and webhooks align with an application repository. The product team can test the message as code and keep delivery traces with the account event that caused the send.

Many B2B SaaS teams use a boundary between those models. Loops handles launch announcements, onboarding, educational sequences and win-back campaigns. Resend handles password resets, invoices, magic links, security notices and other messages where the product must decide exactly when to send. A shared suppression service and clear domain policy matter more than forcing every message into one vendor.

Worked cost scenario: 10,000 contacts and 100,000 monthly sends

Assume a SaaS has 10,000 subscribed contacts and sends 100,000 emails in a month: two newsletters to the full audience (10,000 × 2 = 20,000), four onboarding messages to 5,000 new or active users (5,000 × 4 = 20,000), and 60,000 product notifications. The arithmetic is 20,000 + 20,000 + 60,000 = 100,000 emails. The scenario deliberately includes both marketer-owned and application-owned mail so the pricing units are visible.

For Loops, the closest listed audience point is 9,998 subscribers. Loops lists the Growing Audience Plan at $99 per month at that slider position. Its paid scope includes unlimited sends to subscribers and transactional sends to users outside the audience, so the 100,000-send total does not create a second send-volume line in this scenario. The contact count is the key meter: 10,000 contacts is two contacts above the listed slider readout, so request the exact current audience quote rather than inventing an interpolation.

For Resend transactional delivery, the pricing slider lists Pro at $35 per month for 100,000 emails. If the 100,000 messages are all application sends, the arithmetic is 1 × $35 = $35 per month.

Resend’s marketing slider lists Pro marketing at $80 per month at 10,000 contacts. The combined arithmetic is $35 + $80 = $115 per month before any add-ons. The transactional-only comparison is $35 per month.

The scenario does not make Resend automatically cheaper or Loops automatically better. It shows why the work split matters. A team that wants marketers to manage the two newsletters and onboarding paths may prefer the single contact-based Loops bill. A team that already has audience queries, queues and a React component system may prefer Resend’s $35 transactional tier and keep marketing in its existing stack. Price the people who will operate the system, not just the messages.

How Loops fits a SaaS lifecycle team

Loops is strongest when a SaaS business treats email as a lifecycle program rather than a mail pipe. A marketer can map the journey from signup to activation, paid conversion, expansion and renewal, then ask engineering to expose the events and properties needed for each branch. The contact record becomes the working surface for audience decisions: plan, role, workspace, feature adoption and recent activity can all support a campaign brief.

The contact-based meter changes the planning conversation. Loops lists $99 per month at 9,998 subscribers and $249 per month at 49,989 subscribers. A company with a large but quiet audience should include those records in its forecast because the bill follows subscribed contacts, not only the people who opened last month. The benefit is simple campaign planning once the audience is in place: paid plans list unlimited sends to subscribers and include transactional sends to users outside the audience.

Loops also creates a clear handoff for marketers. A product marketer can own a feature announcement, a growth lead can own trial education and a lifecycle manager can own re-engagement. Engineering still needs to define event names, identity changes, retries and consent, but the day-to-day program does not have to be encoded as a set of application jobs. Use a review checklist for audience membership, links, localization and message class before a send.

The limitation is architectural clarity. If a password reset, invoice or security alert requires a strict queue, an audit trail and application-level fallbacks, do not let campaign convenience hide those requirements. Keep product-critical messages on a deliberate path, whether that is a carefully governed Loops integration or a separate Resend stream.

How Resend fits an engineering-owned email layer

Resend is strongest when sending belongs close to the product code. React Email lets a team express an invoice, invitation or account alert as a component, share layout primitives and review the result in the same process as other application changes. SDKs and a REST API keep the integration small, while message IDs and webhook events make it possible to trace a send from the originating event to delivery status.

The API boundary also makes responsibility explicit. Your application decides whether a user is eligible, which language to use, whether a trial reminder should wait, how many attempts are safe and when a sequence stops. A queue should own timing; a database should own identity and consent; an analytics pipeline should own conversion measurement. Resend then does the sending and returns delivery evidence. This separation is valuable to platform teams that already operate those primitives.

Resend’s pricing slider is based on email volume for transactional plans. It lists Pro at $35 for 100,000 emails. That is a useful planning anchor for an application with a known send volume. The separate marketing slider lists contact-based prices such as $80 per month at 10,000 contacts. Confirm whether your use case is transactional, marketing, or both before comparing a bill to Loops.

The limitation is the work around the API. A marketer who needs to adjust a segment, schedule a campaign or pause a sequence may need an internal tool or an engineer. Build a small message catalog, audience sync and suppression layer before calling Resend a complete lifecycle platform. If that layer already exists, Resend can be a clean and durable delivery boundary.

A practical two-tool architecture

Using both vendors can make sense when message classes have different owners. Put account-critical messages in Resend: password resets, magic links, invoices, payment confirmations, security alerts and operational notices. Put marketer-owned programs in Loops: onboarding education, feature launches, newsletters, trial nudges and re-engagement. Use different subdomains where your deliverability policy calls for separation, and document which system handles each bounce and unsubscribe event.

The important integration is the suppression contract. A person who unsubscribes from marketing should stop receiving Loops campaigns, while a required account alert can follow the product’s transactional policy. A hard bounce should be visible to both systems, and a deleted account should remove or anonymize its contact representation. Store the internal user ID, workspace ID and message class in metadata so support can explain a send without guessing which vendor owns it.

Avoid dual ownership of the same program. If Loops sends an onboarding email and an application worker also sends a similar message through Resend, a user can receive duplicates during a retry or migration. Give each event a single consumer, use idempotency keys, and write a test for a late event, a repeated event and a plan change during a wait step. The two-vendor design is easier to operate when the boundary is visible in code, documentation and the campaign calendar.

Review the split quarterly. Message volume may move from transactional to marketing as the product matures, or a marketer may need a program that was initially hard-coded. Revisit the owner, data path, domain reputation and price meter together. A vendor choice is healthy when the team can move one message class without rewriting every other class.

Migration and rollout steps

Starting with Loops, inventory every current message and label it marketing, lifecycle or transactional. Export contacts, consent state, plan and role properties, event names and suppression state. Build one onboarding path with a small test audience, verify that an activation event stops the right message, then add a newsletter and one product announcement. Keep the old sender read-only until counts, opt-outs and delivery outcomes reconcile.

Starting with Resend, inventory templates, queues, event consumers, webhook handlers and the product fields each message uses. Move React Email components into a versioned package, create a message catalog and persist the provider message ID. Rehearse a bounced address, a duplicate billing event, a revoked consent and a user who changes email. Only after those cases are observable should you move production traffic.

Moving from one vendor to a two-tool boundary needs a message ownership table. For each message, record trigger, audience, consent class, sending domain, template owner, retry owner and destination system. Migrate one class at a time, beginning with a low-risk announcement or internal test. Compare duplicate rate, bounce handling, unsubscribe propagation and support lookup before moving account-critical mail.

1. Name the source of truth for identity, workspace membership, plan, consent and product events.
2. Classify each message as marketing, lifecycle or transactional and assign one sending owner.
3. Create a representative test contact and workspace with plan changes, opt-out, bounce and deletion cases.
4. Verify domains, authentication records, webhook signing, retries, suppression and message metadata.
5. Run one complete campaign or notification cycle, reconcile counts and inspect delivery events.
6. Expand traffic gradually, keep the previous path read-only, and document the rollback switch.

Questions to ask before signing

• Who can launch or pause a campaign without engineering help?
• Which product events and properties must be available before the first lifecycle branch is trusted?
• Does the monthly forecast follow subscribed contacts, transactional email volume, marketing contacts or all three?
• Which messages require React Email, code review, queues, retries and a provider message ID?
• Where will a global unsubscribe, hard bounce or deleted account be propagated?
• Will Loops and Resend use separate domains, and who owns DNS and deliverability incidents?
• What does the support team need to search when a customer asks why an email was sent?
• If both vendors are used, which system is the only consumer for each event and message class?