How to Build Notification Infrastructure: Build vs Buy

TL;DR

There are seven realistic ways to build notification infrastructure. The right one depends on your channels, your team, and whether you're solving a product notification problem, a marketing problem, or both. For most products, a unified platform is the right call. A few should self-host, and very few should build from scratch.

Our recommendation

Courier: use one platform built for humans and AI agents. One API for email, SMS, push, in-app, Slack, Teams, WhatsApp, and Discord. Visual Journeys for orchestration. Drop-in components (Inbox, Preferences, Toasts) so you're not building UI from scratch. An MCP server and CLI so AI coding tools can build, test, and debug notifications without leaving the IDE.

What's changed lately

You still have to pick a notification platform. What changed is what that platform has to handle.

AI agents write notification code now. Cursor, Claude Code, Codex, and Copilot agent mode do more than autocomplete. They build entire notification workflows, set up providers, configure routing logic, and test delivery. The quality of what they produce depends on the context they have access to.

MCP became the standard for AI-tool integration. The Model Context Protocol lets AI coding tools connect to external services: your notification platform, your database, your CI pipeline. Platforms that ship MCP servers give AI agents access to real templates, real channels, and real delivery status. Platforms that don't leave agents guessing from training data.

Notification volume is less predictable. When an AI agent processes 200 tasks overnight, that's 200 potential notification events. The infrastructure that handled "user clicks button, send email" doesn't handle "autonomous system completes variable workload at 3am." You need batching, digests, and throttling to absorb those bursts.

Notification fatigue is the other pressure. More events can't mean more interruptions. Your infrastructure has to respect each user's preferences and pick the channel they'll actually see.

The line between product and marketing notifications blurred. Platforms like Klaviyo own the marketing side. Platforms like OneSignal own push engagement. But you increasingly need both transactional and marketing messages in a single system, with shared preferences, shared user profiles, and unified delivery logs. Running two platforms doubles the integration work and fragments the user experience.

The seven approaches

1. Use one platform built for humans and AI agents (recommended)

This is what Courier does. One API handles every channel. A visual builder handles orchestration. Drop-in components handle the frontend. And AI tooling handles the development workflow.

Why this approach wins

When AI agents write your notification code, context engineering is the deciding factor: giving the agent the real data it needs to produce correct code on the first try.

"I really like the term 'context engineering' over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM." Tobi Lütke, CEO of Shopify

Courier's MCP server connects your AI coding tool (Cursor, Claude Code, VS Code Copilot, Codex) directly to your Courier account with 170+ tools. The agent sees your real templates, your real channels, and your real provider config. When you prompt "add a welcome email with push fallback," it can work from your actual template IDs and the current SDK install guide instead of guessing package names.

{
  "mcpServers": {
    "courier": {
      "url": "https://mcp.courier.com",
      "headers": { "api_key": "YOUR_COURIER_API_KEY" }
    }
  }
}

One config entry. No local install. The agent can send notifications, look up users, read templates, check delivery status, invoke Journeys, and pull current SDK installation guides, all without leaving the IDE.

The CLI covers the API from the terminal:

npm install -g @trycourier/cli
export COURIER_API_KEY=YOUR_COURIER_API_KEY
courier send message \
  --message.to '{"user_id":"user123"}' \
  --message.content '{"title":"Build failed","body":"main is red"}' \
  --message.routing '{"method":"all","channels":["email","inbox"]}'

What you get out of the box

Cross-channel delivery. Email, SMS, push, in-app, Slack, Microsoft Teams, WhatsApp, Discord, webhook. 50+ provider integrations with automatic failover. Switch from SendGrid to Postmark or from Twilio to Vonage by changing the config, not the code.

Visual orchestration. Journeys handle multi-step sequences with branching, delays, and API calls mid-flow. Send push first, wait an hour, check if opened, fall back to email. Non-engineers can modify flows without deploying code. Learn more in our guide on how to build customer journeys.

Drop-in components. Inbox for in-app notification centers. Preferences for user control over channels and topics. Toasts for real-time alerts. See our guide on how to build a notification center.

Typed SDKs. Seven server SDKs (Node, Python, Ruby, Go, Java, PHP, and C#), generated with Stainless from one OpenAPI spec, plus client SDKs for React, JavaScript, iOS, Android, React Native, and Flutter.

Slack and Microsoft Teams notifications. The Slack and Microsoft Teams integration means B2B customers receive notifications where they already work: Block Kit in Slack, Adaptive Cards in Teams, and each customer's Slack token stored on their tenant, so sends land in their own workspace. Check out our guide on building Slack and Teams notifications.

Template design. Design Studio gives product and marketing teams a way to build templates without writing code. You can use code-based templates when you need full control.

Product + marketing in one platform. Password resets and onboarding sequences, order confirmations and re-engagement campaigns, all on shared user profiles, shared preferences, and a single delivery log.

Best for

You need both product notifications and marketing messages, you want AI coding tools to produce correct notification code, and you don't want to maintain integrations with 5+ providers.

Pricing

The Developer plan is free and includes 10,000 sends a month. Business is $0.005 per send. See pricing.

2. Build on open-source

Self-host your notification infrastructure using an open-source framework. Novu is the leading option here with 40K+ GitHub stars (as of November 2026) and an open-core model.

What you get

Novu supports email, SMS, push, in-app (through its Inbox), and chat. There's a workflow builder for sequencing notifications. And Novu offers an MCP server for AI tooling, though it has 23 tools against Courier's 170+.

The real draw is control. You can inspect the source, modify it, and run it on your own infrastructure.

What you'll deal with

Self-hosting means you own uptime, scaling, database migrations, and security patches. It isn't a single Docker container once you add the databases, queues, and redundancy production needs.

Best for

You have strict data residency requirements, strong DevOps capabilities, or you want to modify the source code directly.

3. Use a push-first engagement platform

Platforms like OneSignal started with push notifications and expanded into email, SMS, and in-app messaging. They're strong at mobile engagement, especially push, which is their foundation.

What you get

OneSignal supports mobile push, web push, in-app messaging, email, and SMS. Its Journeys feature is a visual workflow builder. SDKs cover iOS, Android, React Native, Flutter, and web. OneSignal also has an official MCP server, in open beta as of November 2026.

What you'll deal with

OneSignal is built around push engagement, and it's strong there. B2B products need more.

Its integrations page doesn't list Slack or Microsoft Teams, so B2B chat notifications mean third-party automation or custom code. We didn't find a drop-in notification center component for your web app.

If you need Slack, Teams, an in-app inbox, and cross-channel orchestration for a B2B product, you'll likely outgrow it.

Best for

Mobile-first products where push notifications drive engagement, retention, and re-activation. Consumer apps, gaming, media, and e-commerce with a strong mobile presence.

Pricing

As of November 2026, the free plan includes unlimited mobile push for up to 1,000 monthly active users, 10,000 email sends a month, and three active Journeys. The Growth plan starts at $19/month plus usage.

4. Use a marketing-oriented platform

Platforms like Klaviyo are built for marketing teams. They own email campaigns, SMS marketing, and customer lifecycle campaigns, with deep e-commerce integrations and sophisticated audience segmentation.

What you get

Klaviyo supports email, SMS, and mobile push notifications. The platform excels at audience segmentation, lifecycle flows (abandoned cart, post-purchase, winback), A/B testing, and revenue attribution. There's a drag-and-drop email editor, a flow builder with conditional branching, and deep integrations with Shopify, BigCommerce, WooCommerce, and other e-commerce platforms. Klaviyo offers an MCP server for AI-assisted campaign creation and flow management.

Klaviyo is publicly traded (NYSE: KVYO) with over 205,000 customers (as of June 30, 2026).

What you'll deal with

Klaviyo is a marketing platform, not notification infrastructure. Its tooling is built around marketing audiences, campaigns, and flows. Push notifications require a mobile app with Klaviyo's SDK and have a 512-character body limit (Klaviyo suggests about 178 characters for iOS display).

The free plan caps at 250 active profiles and 500 email sends a month, which is useful for testing, not for production. Pricing is based on contact count, not send volume, which can get expensive as your user base grows.

Transactional notifications (password resets, order confirmations, security alerts) are secondary to Klaviyo's marketing focus. If your primary need is product notifications that engineering controls, Klaviyo isn't the right tool.

Best for

E-commerce and D2C brands where marketing email and SMS drive revenue. The marketing org owns the notification strategy, and engineers are less involved in day-to-day notification management.

5. Stitch together best-of-breed providers

Pick the best provider for each channel: SendGrid for email, Twilio for SMS, Firebase for push, your own WebSocket server for in-app. Write the orchestration layer yourself.

When this makes sense

You have deep expertise with specific providers, strong opinions about email deliverability or SMS routing, and engineers who want full control over each channel's implementation.

What you'll deal with

Five different authentication systems. Five different rate limit policies. Five different retry mechanisms. Five different webhook formats for delivery status. User preferences stored in five different places. No unified view of what got delivered where. Every new channel is a new integration project.

The orchestration layer (the thing that decides "send push first, wait, check if read, fall back to email") is the hardest part, and it's entirely your responsibility.

Best for

You have a large team (10+ engineers on infrastructure), established provider relationships, and genuinely unique requirements that no platform addresses.

6. Use your cloud provider's native services

AWS SNS + SES + End User Messaging. Google Cloud Pub/Sub + Firebase Cloud Messaging. Azure Notification Hubs + Communication Services. Stay in your cloud ecosystem.

When this makes sense

You're deeply committed to a single cloud provider, you already know the APIs, and you want billing consolidated.

What you'll deal with

Cloud notification services are building blocks, not solutions. SNS handles pub/sub, but it doesn't manage user preferences, build notification centers, batch bursts of events, or provide visual template editors. You'll write significant glue code, and the developer experience usually means more configuration and less abstraction than a dedicated notification platform.

You also build the drop-in components, preference management, and visual workflow builder yourself, and your AI coding tools get no context about your notification setup.

Best for

You prioritize cloud vendor consolidation above developer experience and feature completeness.

7. Build from scratch

Design the queue, build the routing engine, implement the preference store, create the template renderer, handle provider failover, build the observability layer, maintain it all.

When this makes sense

You send 100M+ notifications monthly. You have dedicated infrastructure engineers. You're willing to invest months in initial development plus ongoing maintenance. Provider negotiation and cost optimization is a core competency.

At that scale, a dedicated notification team can pay for itself. For most products, it can't.

What you'll deal with

Exponential backoff with jitter for retries. Dead letter queues for permanently failed messages. Circuit breakers for flaky providers. Timezone-aware delivery scheduling. Cross-channel state synchronization (did the user read the push? don't send the email). GDPR-compliant preference management. Rate limiting per provider, per channel, per user. Observability across every hop.

This is real infrastructure work. The initial build is the easy part. Maintenance, scaling, and reliability are where the years go.

Best for

You have 20+ engineers on infrastructure, 100M+ monthly notifications, and truly unique requirements that no platform addresses.

Comparison matrix

How to choose

Answer these five questions:

1. How many channels do you need? If the answer is "email and SMS for marketing only," a platform like Klaviyo handles it well. If it's "push for a mobile app," OneSignal is strong. If you need email, push, in-app, Slack, and Microsoft Teams from one API, with provider abstraction and automatic failover, that's where a unified platform like Courier makes sense. Start with what you need today, but plan for the channels you'll want 12 months out. For the design principles behind reaching users across all of them, see our guide to the future-proof multichannel notification system.

2. Who needs to modify notification flows? If product, growth, or marketing teams need to iterate on notifications, you need a visual builder and template editor. OneSignal and Klaviyo have visual builders geared toward their respective audiences (mobile engagement and marketing campaigns). Courier's Journeys handle both product and marketing flows.

3. Do you use AI coding tools? If you build with Cursor, Claude Code, or similar tools, platform choice directly affects code quality. Courier, Novu, Klaviyo, and OneSignal all offer MCP servers, but the depth varies. Courier's has 170+ tools covering send, templates, users, delivery logs, Journeys, preferences, and SDK installation guides, plus JWT generation. Evaluate what your AI agent actually needs access to.

4. Do you need both product and marketing notifications? This is the one that's easiest to get wrong. You start with transactional (password resets, receipts) and figure you'll add marketing later. Then marketing wants onboarding sequences. Growth wants re-engagement. Suddenly you're running one platform for product and another for marketing, with user preferences split across two systems. If you see both in your future, start with a platform that handles both, like Courier.

5. What's your compliance situation? GDPR requires consent or another lawful basis, and CAN-SPAM requires honoring opt-outs, so you need preference management that holds across every channel. HIPAA applies if your notifications carry protected health information. If your security team asks for SOC 2 Type 2 documentation, make sure your platform has it.

The architecture that actually works

Here's the notification architecture pattern that scales:

Your Application
       │
       ▼
  Single API Call ──────────► Notification Platform
  (template + user + data)         │
                                   ├── Orchestration Layer
                                   │   (routing, preferences, delays, conditions)
                                   │
                                   ├── Template Engine
                                   │   (per-channel rendering, i18n, personalization)
                                   │
                                   ├── Provider Layer
                                   │   (failover, rate limiting, retries)
                                   │
                                   └── Observability
                                       (delivery status, logs, debugging)

Your application sends one API call. That's it. Template, user ID, data payload. Your code doesn't know or care about channels, providers, or rendering.

POST /send
{
  "message": {
    "to": { "user_id": "user-123" },
    "template": "order-shipped",
    "data": {
      "order_id": "ORD-4821",
      "tracking_url": "https://track.example.com/4821"
    }
  }
}

The orchestration layer handles routing. User preferences determine which channels. Journey logic determines the sequence. Batching and digests handle volume. The routing decision happens at send time, not at code time.

The template engine handles rendering. One notification, rendered differently for email (HTML), push (title + body), Slack (Block Kit), in-app (structured JSON). Courier's Design Studio handles this per-channel rendering without duplicating templates.

The provider layer handles delivery. SendGrid fails? Courier retries, then routes to the next provider you've configured. Each provider's quirks are abstracted away. 50+ integrations mean you can switch providers without touching your code.

Observability closes the loop. Did it deliver? Did the user open it? Did the provider bounce it? Filterable logs by user, message, provider, or status. On Enterprise, Datadog and New Relic integrations put notification delivery alongside application performance.

Courier applies this architecture across every channel (product and marketing, transactional and lifecycle) in one platform with 50+ swappable providers. Building it yourself means owning every layer above.

How top companies build notification infrastructure

Twilio had Console alerts spread across Segment, SendGrid, and hand-coded logic. It embedded Courier's Inbox in the Console to give its 10 million developers one real-time feed.

"We chose Courier because the depth of the inbox and multi-channel integrations allowed us to choose one notification platform for all products and teams at Twilio." Raghav Katyal, Technical Lead, Twilio

LaunchDarkly sends approval notifications to customers' Slack instances through Courier's webhook channel, so any Slack instance with LaunchDarkly installed can receive them.

Fluint chose Courier as its notification foundation, expanding from email to multi-channel delivery while freeing engineers to focus on the core product.

Nav couldn't launch its business checking account without real-time alerts for transactions, large deposits, and new-device sign-ins. It started with email through SendGrid on Courier's Send API, then added push and SMS through Twilio.

"A full team had struggled for years to make progress. When we turned to Courier, we launched multi-channel notifications in a couple of months." Ammon Lockwood, Nav

Getting started

Notification infrastructure is one of those backend systems that seems simple until you build it. The complexity hides in the edges: provider failover, timezone-aware scheduling, cross-channel state sync, preference enforcement, and the orchestration logic that ties it all together.

If you're starting from scratch, here's the order of operations:

1. Pick your channels. If you see Slack or Microsoft Teams in your future, factor that into your platform choice now. Not every platform handles them well.

2. Set up AI tooling. If you're building with Cursor or Claude Code, add the MCP server config from approach 1 before you write a line of notification code. Your agent will produce better code from the start.

3. Install the SDK. Pick a server SDK for sends and a client SDK if you're adding in-app UI. The SDK overview lists them all, and the API reference covers every endpoint.

4. Send your first notification. Use the CLI to test immediately:

npm install -g @trycourier/cli
export COURIER_API_KEY=YOUR_COURIER_API_KEY
courier send message \
  --message.to '{"user_id":"user123"}' \
  --message.content '{"title":"Hello","body":"First notification"}' \
  --message.routing '{"method":"all","channels":["email","inbox"]}'

5. Build your first Journey. Use the visual builder to create a multi-step flow. Start with something small: send email, wait, check if opened, send push if not. See our guide on how to build customer journeys.

6. Add drop-in components. Inbox and Preferences are a lot of UI to build from scratch. The drop-in components cover both.

Ready to build notification infrastructure? Start free with 10,000 sends a month, or book a demo to see Journeys and drop-in components in action.

Frequently asked questions

Can an AI agent delete data through Courier's MCP server?

Yes. The server exposes delete tools such as delete_profile, delete_list, delete_tenant, and delete_provider, and the tools reference marks which tools write. API keys are scoped to one environment, so give your agent a key for a non-production environment while it builds and tests.

What's the difference between the MCP server and the CLI?

The MCP server exposes the Courier API as typed tools that your AI coding tool discovers and calls on its own. The CLI runs the same API from your terminal or a script. Use MCP when an agent is doing the work, and the CLI when you or your CI pipeline are.

Sources

1. Customer case studies: Courier
2. MCP architecture overview: Model Context Protocol