Disclosure first: I build Notavia. This is a launch post, but I've written the thing I'd have wanted to read — what it does, what it deliberately doesn't, and where the edges are.
The problem I kept re-solving
Every SaaS product eventually has to tell a user something. A new invoice. A failed sync. A teammate's comment. A security alert at 2am. You need that message to reach whichever channel the user is actually paying attention to, and you need to know it arrived.
I have written that layer more than once. It always starts as "just send an email" and ends as a scheduled job, a half-finished retry queue, provider credentials in three places, and no reliable answer to "did it actually get delivered?"
Notavia is that layer, built once, properly.
One call
await notify.Notifications.SendAsync(new SendNotificationRequest(
Channel: "email",
Recipient: new Recipient("ada@example.com"))
{
TemplateKey = "welcome",
TemplateData = new Dictionary<string, object?> { ["name"] = "Ada" }
});
Notavia looks up the recipient's channel preferences, renders the template for each active channel, dispatches, and gives you a replayable delivery log — without you managing per-channel provider credentials or writing the same routing logic for the fourth time.
The four channels that are actually live
Email — your own SMTP relay or any compatible provider. Paid plans include managed EU sending with no provider setup at all. Custom sender domains, GDPR-clean unsubscribes, suppression lists.
In-app inbox — a real-time notification bell for your product: unread counts, mark-as-read state, full history. In .NET this is a drop-in Blazor component, not a JavaScript widget with a C# footnote bolted on.
SMS — your own Twilio or Vonage credentials. There is no managed SMS option, and I'd rather say that than let you find out later.
Chat — Slack, Microsoft Teams, and Discord. Mostly useful for internal tooling and DevOps alerting, where your users are developers who live in those apps.
Push is on the roadmap. The architecture is there; I'm still working through certificate management and TTL edge cases, and I'm not calling it production-ready until that's done.
One template, every channel
This is where most of the time went. Templates are written in Scriban — logic-capable, and it renders cleanly to HTML, plain text, and short-form message bodies. You write one template per event type and Notavia renders the right variant per channel.
Templates are runtime-editable, so tenant administrators can change the copy through the console without a deployment. You ship the default; your customers adjust the wording for their brand.
The .NET-first part
The API is plain REST and works fine with no SDK at all. But the reason this exists is that the .NET ecosystem usually gets the afterthought client, so:
- SDKs published for .NET, TypeScript, Python, Go, and PHP — on NuGet, npm, PyPI, the Go proxy, and Packagist
- A Blazor inbox component with real-time updates
- An MCP server, so an AI editor can wire notifications into your app by talking to the API directly
- White-label throughout: per-tenant sender domains, branded inbox, hosted unsubscribe pages
What it costs
Free forever at 1,000 sends a month, no card required. On the free plan you bring your own provider keys; managed sending is on the paid plans.
If you want to try it: the first 20 teams get assisted onboarding, an architecture review, and the Growth plan at the Starter price for their first 60 days. Reply here or email hello@saas-infrastructure.com and say "founding".
Happy to answer anything — architecture, the template system, why Scriban, how the delivery log works, or what I'd do differently. Ask away.
Top comments (0)