In-app notifications without a notification platform

Most “we need notifications” conversations in a small SaaS are about one thing: a bell icon that shows your export is ready, someone commented, your trial ends Friday. That is a table and a polled endpoint. The platforms exist for a different problem, and it is worth knowing which one you have before paying for the other.

What the bell actually needs

• A row per notification: user id, title, body, a link, created and read timestamps.
• A way to create one from your server when something happens.
• An endpoint the client can call to get the unread ones, with a key that is safe in a browser, and a check that the browser is asking about its own user.
• A way to mark one as read.
• Pruning, so the table does not grow forever.

That is the whole product. Polling every 30 to 60 seconds is fine: a tab makes one small request a minute, the endpoint returns a short list, and the badge updates. Nobody notices a 30-second delay on your export is ready.

When that stops being enough

Three things move you to a platform.

Channels. The moment the same event should also go out by email, SMS or push, you need templates per channel, delivery tracking, bounce handling and a place to see what went out. That is what Knock, Novu and Courier are.

Preferences and digests. “Email me daily, not per event”, quiet hours, per-category opt-outs, batching ten comments into one message. Building this well is weeks of work; the platforms have it on the free tier.

Volume. With tens of thousands of concurrently active users, polling becomes a cost line and a socket-based feed is cheaper. All three platforms ship an in-app feed component that handles this.

The three platforms, briefly

Knock is notification infrastructure with the deepest workflow tooling: batching, digests, preference center, send windows, version control for workflows, and an in-app feed. The free Developer plan covers 10,000 messages a month; the first paid plan is $250 a month. There is a CLI and an MCP server.

Novu is open source and can be self-hosted or managed. Workflows across in-app, email, SMS, push and chat, an <Inbox /> component, digests, preferences, quiet hours. The free plan has 10,000 workflow runs a month; Pro starts at $30. An MCP server with 23 tools.

Courier is a notification API with a visual template editor and multi-step journeys across email, SMS, push, Slack, Teams and an in-app inbox, priced per send after a free 10,000 sends a month. It has a hosted MCP server and a CLI.

The polling version, in full

If your situation is the bell and nothing more, here is all of it. The server side is one insert; the client side is one interval.

// server: after the export finishes
await db.insert(notifications).values({ userId, title: "Your export is ready", url: "/exports/42" });

// server: GET /api/notifications/unread → the signed-in user's last 20 unread rows
//         (take the user from the session, never from the query string)
// server: PATCH /api/notifications/:id/read

// client
async function poll() {
  const r = await fetch("/api/notifications/unread");
  render(await r.json());
}
poll();
setInterval(poll, 30_000);

Add a daily job that deletes rows older than 90 days and you are done.

Where Launch fits

Nordva Launch’s notifications primitive is that polling version, hosted, so you do not write the table or the endpoints:

• POST /v1/notifications sends to a user id you choose, or to everyone with audience: "all"; there is no user directory to sync.
• GET /v1/notifications/inbox is called from the browser with a publishable key and answers with the user’s recent notifications, the unread count and poll_interval_seconds.
• The browser proves which user it is with user_hash, an HMAC-SHA256 of the user id that your server computes with a signing secret the browser never sees. Without it, anyone with the page’s key could ask for another user’s notifications.
• PATCH /v1/notifications/{id}/read marks one read for that user. A broadcast is read separately by each person. Rows are pruned after 90 days.
• A changelog entry can post itself to the bell when it publishes.
• Sending accepts an Idempotency-Key, so a retried job never sends twice.
• The MCP tools send_notification, get_unread_notifications and mark_notifications_read let an agent do the same.

It is on every plan (1,000 notifications a month per project on Free, 20,000 on Indie, 200,000 on Builder), next to the changelog, waitlist, feedback and revenue primitives on the same key. It has no channels other than in-app, no preferences, no digests and no socket feed.

Who should not use Launch for this

If you send by email, SMS or push, or need preferences and digests, use Knock, Novu or Courier; all three start free and Launch cannot do those things. If you already run one of them, their in-app feed is included and there is no reason to add a second in-app system.