Build vs buy notification infrastructure, honestly (and why AI coding made it worse)

A product manager files a ticket: “Send users an email when their report is ready.” You wire up an API call to your email provider, template the subject line, and ship it that afternoon. It works. Everyone is happy.

But it doesn’t stop there. Next, you’re including more channels, support for different vendors for those channels, notification delivery tracking and the ability of your users to set preferences, and schedules for receiving notifications. And a year down the line, you find yourself building a notification infrastructure.

None of this is new, in fact we covered this in a previous article. What’s new is that AI now writes that first version for you in minutes, but has it made it cheaper to own? This makes it the right time for us to revisit the build versus buy decision. This article gives you an honest framework for deciding what to build, where the cost really lives, why cheap code makes the call harder rather than easier, and a rough model you can run against your own numbers.

Key takeaways

The trap: version one is always easy

Version one of a notification feature often looks like a provider call inside your application. It may look as straightforward as this:

async function notifyReportReady(user: User, report: Report) {
  await sendgrid.send({
    to: user.email,
    from: "[email protected]",
    subject: `Your report ${report.name} is ready`,
    html: renderTemplate("report-ready", { user, report }),
  });
}

If your entire notification surface is one transactional email and it never grows, you are done. Genuinely. Stop reading and go build it.

The problem however is that this is never where it stops. The next ticket asks for a Slack message instead of email or for in-app notification in the dashboard. Another ticket to let your users choose between email and in-app notification or to choose the time they want to receive notifications.

Each request looks manageable in isolation. Together, they create a delivery system with state, timing, provider-specific behavior, and failure modes.

The real cost is maintenance, not v1

You are no longer estimating the cost of sending a message. You are estimating the cost of owning the system around it. The build-versus-buy decision starts when you recognize that difference.

Let’s walk through some of the things that actually land on your plate. The exact scope depends on your product, but the ownership surface commonly includes:

Not every company needs every row on day one. The mistake is pricing only the rows required today while assuming the rest will remain unnecessary.

Use a realistic planning horizon instead. Ask what the product is likely to require over the next 12 to 24 months, how difficult each addition would be, and whether your first implementation preserves a migration path.

The AI twist: code got cheap, ownership did not

Here is the part that actually changed, and most takes get it backwards. A few years ago, “we could just build it” was throttled by the cost of writing version one, and it was often enough to make a team pause and reach for a platform instead.

Now a coding assistant writes that first version in ten minutes. You describe the notification service and it hands you the sender, the template renderer, a queue consumer, even a first pass at retry logic. The friction that used to make teams stop and think has mostly evaporated.

The popular framing reads that as a point in favour of building. If the code is nearly free to produce, why pay anyone for it? That framing is having a moment right now, and it is wrong in a specific way. It prices the wrong thing.

Look again at where the cost actually lives. It was never in creating the first version. It is in owning and operating the system. AI made the cheap part cheaper and did nothing for the expensive part. Build versus buy was always a question about who owns the maintenance. AI changed the cost of the part that was never the problem.

There is a second thing you are buying that the “code cheap” framing misses entirely: knowing what good looks like. We have spent five years building notification infrastructure, and most of that time went in perfecting the notification experience for your users so that you can focus on building what actually matters to you.

A build-vs-buy decision framework

The right answer depends on the system your product is likely to need, the responsibilities your team can support, and which parts of notification delivery create product value. Start with these five questions.

1. 1

   How many channels will you need within the next 12 to 24 months?

   One stable channel is a stronger build signal. Every additional channel introduces its own providers, payload formats, credentials, templates, limits, and failure modes. Avoid requiring certainty “forever.” Use a realistic planning horizon and consider the cost of migration if the assumption changes.

2. 2

   Do subscribers need preferences or schedules?

   A preference center turns simple send code into a policy system. Once subscribers can choose message types, channels, or availability, the same rules must apply across every service that triggers a notification.

3. 3

   What happens when delivery fails?

   A missed digest may be inconvenient. A missed password reset, trade confirmation, or security alert can create support, trust, or compliance consequences. Higher stakes require stronger retry behavior, observability, and operational ownership.

4. 4

   Who owns the system after launch?

   Name the team, not the person who happened to write version one. The owner needs capacity for provider changes, incidents, security updates, feature requests, and migrations.

5. 5

   Which parts of notifications differentiate your product?

   Users may value timely financial alerts, configurable monitoring, incident routing, or a strong in-app experience. That does not mean your team must build every queue and provider integration behind them. Separate the experience that differentiates the product from the repeatable infrastructure that supports it.

6. 6

   What uptime do you need, and who carries the on-call responsibility?

   Set the availability target before you choose an approach. Higher uptime requires monitoring, redundancy, capacity planning, recovery procedures, and engineers who can respond when the system fails outside working hours. A managed platform shifts the underlying platform uptime and infrastructure response to the vendor. A custom build or self-hosted platform leaves that responsibility with your team.

Tally your answers. Multi-channel, preference-heavy, high-stakes, unowned, and non-differentiating points hard at buy. Single-channel, no preferences, low-stakes, clearly owned, and core to the product points at build. Most teams land closer to buy than they expect, because they answer question one as “just email” and question two as “not yet,” and both are usually wrong within a year.

When you should actually build

Buying is not always right, and pretending otherwise is how vendors lose credibility. Three cases where building is the correct call.

Outside those, the honest answer is usually buy, or self-host something that already exists.

What buying actually offloads

The pitch for buying is not “less code,” though it is that too. It is that you stop owning the maintenance categories from earlier. A notification platform absorbs:

• Retry, backoff, idempotency, and dead-letter handling as a managed workflow engine, not code you keep patching.
• A provider abstraction across channels, so a provider swap is configuration, not a refactor.
• A preference and subscription layer with per-channel, per-category, timezone-aware logic, built and enforced at send time.
• Template management your non-engineers can edit without a deploy.
• Deliverability tooling and provider health, so a degraded provider is the platform’s problem instead of your pager’s.
• Observability into every message: sent, delivered, failed, retried, and why.

40k starsNovu on GitHub

This is what we built Novu Notify to do. It orchestrates product and transactional notifications across email, SMS, push, in-app Inbox, and chat like Slack, through one API and a drag-and-drop workflow builder, with an embeddable Inbox component for the in-app feed. And if you have an agent that you want your users to communicate with, we built Novu Connect for that.

Novu is open source, so you can self-host the whole thing if data residency is your constraint, or run it on our cloud if it is not.

A rough TCO (Total cost of ownership) model

The point is not only that building takes longer. It is that building costs multiples more, and that part rarely survives into the decision. So here is the high-level version before any line items.

We modeled a production notification system at a realistic scale: five million notifications a month, owned over three years, with engineers at $150,000 a year fully loaded. Built from scratch, that system takes about seven months to launch and runs roughly $640,000 in total cost of ownership across the three years. Measured against that build:

• Self-host a pre-built platform, where you own and run the infrastructure but a company owns the software, and you launch roughly four months sooner at five to six times lower cost.
• Buy a fully managed platform, where the company runs both the software and the infrastructure, and you launch roughly six months sooner at nine to eleven times lower cost.

Those figures are total cost of ownership over the full three-year horizon.

Where does that $640,000 go? Barely any of it is version one. AI made the first send cheap, and it is close to a rounding error against the total. The weight is in everything the model has to account for after: the omni-channel workflow engine, content authoring with dynamic variables (the single largest line item), preferences and defaults, digests and scheduling, targeting and fanout, then the recurring drip of maintenance, quarterly upgrades, and new channels, plus hosting for the queues, databases, and application servers.

That recurring load alone runs on the order of $65,000 a year in the model, before you count the features particular to your product that team did get to work on because they had to manage the notification infrastructure.

Uptime and on-call increase the ownership cost

And even that understates uptime. The model targets 99.5 percent availability, and notes in its own margin that going higher means major additional investment: duplicated infrastructure, and zero-downtime deploys and upgrades.

Uptime is not a line you pay once. It is a standing commitment, and it is the cost teams underestimate most. Buying collapses the build months and hands most of that recurring load, uptime and on-call included, to a team whose whole job is to carry it.

The analogy buyers reach for on their own

We’ve been in lots of calls with teams across different industries, and the same realization repeats: v1 was easy, year two was a slog. An engineer in one of the calls with us put it flatly: why did we choose to build this ourselves.

One of the analogies they reach for, unprompted, is payments. Nobody builds their own payment processor anymore. A payments platform exists, it handles the boring, high-stakes, compliance-heavy, endlessly maintained parts, and you integrate it and move on. Not because you could not build a payments system, but because it would be a bad use of your engineers to own that maintenance forever when the differentiator is your product, not your card-processing retry logic.

Notifications are following the same path. High-stakes, boring when they work, painful when they break, endless to maintain, and not your differentiator. The question stopped being “can we build this,” because with AI you obviously can, before lunch. The question is whether you want to own it for the next three years or more.

Where to land

Run the five questions against the system your product is likely to need, not only the provider call you can ship today. Price custom, managed, and self-hosted options over the same period. Include the work each option retains, the risks each introduces, and the product work your engineers would otherwise complete.

If notification delivery is a core capability and your team is prepared to operate it, build the parts that create that advantage. If your requirements are common and the ownership surface pulls engineers away from the product, adopt an existing foundation.

To evaluate the Novu path, book a call with our team or check out our documentation.

Build notifications faster with Novu MCP

Give your AI the tools to deliver notifications across channels.

Get started