In-App Notifications & Activity Feeds: Build a Notification System That Doesn't Become Spam

In-App Notification Strategy for Your New SaaS

Goal: Ship in-app notifications and activity feeds customers actually use — events recorded with the right granularity, delivered to the right channel (in-app / email / push) per user preference, batched intelligently, marked read/unread reliably, and tunable so users don't drown in noise. Avoid the failure modes where founders ship "notify on everything" (becomes notification fatigue; users disable everything), couple notifications tightly to email-sending code (entangled mess), or forget that notifications need a feed UI (users get one and assume that's all).

Process: Follow this chat pattern with your AI coding tool such as Claude or v0.app. Pay attention to the notes in [brackets] and replace the bracketed text with your own content.

Timeframe: Notification-events table + bell icon UI shipped in 2-3 days. Per-user preferences + email + batching in week 1. Real-time delivery + mobile push (if applicable) + audit in week 2. Quarterly noise review baked in.

Why Most Founder Notification Systems Are Broken

Three failure modes hit founders the same way:

Notify on everything. Founder thinks "more notifications = more engagement." Ships a system that pings users on every comment, mention, status change, like, view, share. Users see 47 unread; they ignore them; they disable email; they file support tickets asking "how do I turn this off"; the engagement metric the founder hoped for goes the wrong way.
Tight coupling to email-sending code. Notification creation is intertwined with email delivery. Adding a new notification type requires touching email templates, throttling, retry, audit. New channels (mobile push, Slack) require rebuilding. The system can't evolve without rewriting.
No central feed. Users see a notification toast briefly, miss it, and have no way to find it later. They contact support: "did you ping me about X?" You can't easily answer because you didn't store the notifications, just sent emails.

The version that works is structured: notifications as first-class events, decoupled from any specific delivery channel, persisted with per-user state, batched intelligently, with per-user channel preferences and a central feed UI.

This guide assumes you have already done Authentication (notifications are user-scoped), have shipped Multi-Tenant Data Isolation (workspace events are different from cross-workspace events), have considered Notification Providers (Knock, Courier, MagicBell — covered later), have shipped Email Deliverability (email digests need this), and have shipped Audit Logs (events feed both audit and notifications).

1. Define Your Notification Types Carefully

Before writing code, decide which events generate notifications. Be conservative; you can always add more.

Help me design the notification catalog for [my product].

The pattern:

Define notifications in a typed catalog. Each notification has:
- A unique type key (e.g., `comment.mention`, `task.assigned`)
- A category (so users can opt in/out by category)
- Default channels (in-app / email / push / off)
- A rendering template (how it shows up in the UI)
- A digest-eligibility flag (can it be batched into a daily digest?)

**Common categories**:

- **Mentions / direct interactions** (high signal): "Alice mentioned you in [Document]"
- **Assignments** (high signal): "Bob assigned you a task: [Task name]"
- **Status changes on things you own** (medium): "Your project [X] was approved"
- **Comments / replies** (medium): "Carol replied to your comment"
- **Activity in spaces you watch** (low-medium): "[New document] in [Watched folder]"
- **Workspace announcements** (low): "Workspace settings updated"
- **Marketing / product updates** (low): "Try our new feature"

**Rules for the catalog**:

1. **Default to NOT-notifying.** Add a notification only when there''s a clear reason. The default state of a new event should be silent.
2. **Categorize tightly.** Three categories with 5 types each beat one bucket of 30 types.
3. **Different defaults per category.** Mentions default to in-app + email; activity defaults to in-app only.
4. **Write the user-visible copy at design time.** "[Actor] [verb] [object]" templates force clarity.

**Anti-patterns to avoid**:

- "All events become notifications" — guaranteed notification fatigue
- "Notification per database insert" — couples DB schema to UX
- "Different products inside one app each invent their own notifications" — fragmentation
- "Email-only notifications" — users on web miss them

**The user-preference model**:

For each notification type, the user has a preference: in-app, email, push, off. Defaults you set; users override.

preferences = { 'comment.mention': { in_app: true, email: true, push: true }, 'task.assigned': { in_app: true, email: true, push: false }, 'document.viewed': { in_app: false, email: false, push: false }, // off by default ... }


For my product:
1. List the events that should generate notifications
2. Categorize them
3. Decide the defaults per category
4. Write the user-visible copy

Output:
1. The notification catalog as a typed schema
2. The category structure
3. The defaults per type
4. The copy templates
5. The list of events you''re explicitly NOT notifying on (and why)

The biggest unforced error: shipping too many notification types in v1. Better to ship 5 well than 30 poorly. You can add more; you can''t take them away without confused users.

2. Store Notifications as First-Class Events

Notifications are persistent data, not transient messages. Build the schema.

Design the storage.

The pattern:

```sql
CREATE TABLE notifications (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  recipient_user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  workspace_id UUID REFERENCES workspaces(id) ON DELETE CASCADE,  -- NULL for global
  type TEXT NOT NULL,                  -- 'comment.mention', 'task.assigned', etc.
  actor_user_id UUID REFERENCES users(id),  -- who did the action
  subject_type TEXT,                    -- 'document', 'task', etc.
  subject_id UUID,                      -- the object the notification is about
  data JSONB NOT NULL DEFAULT '{}',     -- type-specific payload (e.g., comment text)
  read_at TIMESTAMP,                    -- NULL = unread
  archived_at TIMESTAMP,                -- soft hide (kept for history)
  created_at TIMESTAMP NOT NULL DEFAULT NOW(),
  delivered_email_at TIMESTAMP,         -- when delivered via email (if any)
  delivered_push_at TIMESTAMP,          -- when delivered via push (if any)
  digest_id UUID                        -- if part of a digest, the digest record
);
CREATE INDEX idx_notifications_recipient_unread
  ON notifications(recipient_user_id, created_at DESC)
  WHERE read_at IS NULL AND archived_at IS NULL;
CREATE INDEX idx_notifications_recipient_all
  ON notifications(recipient_user_id, created_at DESC)
  WHERE archived_at IS NULL;

CREATE TABLE notification_preferences (
  user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  notification_type TEXT NOT NULL,
  in_app_enabled BOOLEAN NOT NULL DEFAULT TRUE,
  email_enabled BOOLEAN NOT NULL DEFAULT TRUE,
  push_enabled BOOLEAN NOT NULL DEFAULT FALSE,
  email_frequency TEXT NOT NULL DEFAULT 'instant',  -- 'instant' | 'daily' | 'weekly' | 'never'
  PRIMARY KEY (user_id, notification_type)
);

Critical implementation rules:

One row per recipient. A mention to 5 users = 5 rows. Don''t store one row with recipients array — querying becomes hell.
The data JSONB field holds type-specific context. For a comment notification, the comment text and link. For an assignment, the task name and URL.
Archive instead of delete. A user clears their feed; the row stays for history (audit, future "show all" UI).
Index for the unread feed query. This is the hot path; user comes to the page; query has to be fast.

Don''t:

Couple notifications to email message IDs (different concerns)
Store rendered HTML in the row (re-render at read time)
Over-normalize (data JSONB is fine; don''t split into 12 sub-tables)

The actor pattern:

Notifications usually have an "actor" (who did the thing). Store actor_user_id. If the actor is the system (no user), use NULL and treat in rendering: "Your subscription was updated" (no actor) vs "Alice updated your subscription" (actor).

Self-action exclusion:

Don''t notify users about their own actions. Alice commenting on a thread Alice is subscribed to shouldn''t generate a notification to Alice. Filter this in the creation logic, not the read query.

Subject-link rendering:

Each notification points to a subject (document, task, etc.). Store subject_type + subject_id so you can:

Render "View [subject title]" links
Group notifications by subject ("3 new comments on this thread")
Mark all-related-to-X read on a single click

Output:

The notifications schema migration
The preferences schema migration
The notification-creation function with self-action filter
The unread-count query with index hint


The biggest performance pitfall: **un-indexed unread queries.** A user with 10K notifications and no `WHERE read_at IS NULL` index will lock the table on every page load. Index the unread query specifically; it''s the hot path.

---

## 3. Decouple Creation From Delivery

Creating a notification (recording the event) is separate from delivering it (sending email / push / in-app realtime). Don''t intertwine.

Design the creation-vs-delivery separation.

The pattern:

Phase 1: Create

When a triggering event happens (comment created, task assigned):

Determine recipients (subscribers, mentioned users, watchers)
Filter out actor (don''t notify self)
Filter by user preferences (skip if all channels off)
Insert one row in notifications per recipient
Enqueue a delivery job per recipient

Code shape:

async function notifyMention(commentId: string, mentionedUserIds: string[]) {
  for (const userId of mentionedUserIds) {
    if (userId === actorUserId) continue
    const prefs = await getPreferences(userId, 'comment.mention')
    if (!prefs.inAppEnabled && !prefs.emailEnabled && !prefs.pushEnabled) continue
    
    const notification = await db.insert('notifications', {
      recipient_user_id: userId,
      type: 'comment.mention',
      actor_user_id: actorUserId,
      subject_type: 'comment',
      subject_id: commentId,
      data: { commentText, parentDocumentId, ... },
    })
    await enqueueDelivery(notification.id)
  }
}

Phase 2: Deliver

The delivery worker:

Reads the notification row
Re-checks user preferences (might have changed since creation)
For each enabled channel:
- In-app: push to user''s websocket / SSE if connected; otherwise wait for next page load
- Email: render the email; send via transactional provider; update delivered_email_at
- Push: send via mobile push provider; update delivered_push_at
Handle delivery failures (retry / backoff)

Why this matters:

The creation logic is product code (knows who/what)
The delivery logic is infrastructure code (knows how to send)
Adding a new channel (Slack, Microsoft Teams) doesn''t require touching every notification site
Failures in one channel don''t affect others

Critical implementation rules:

Idempotent delivery. Re-running the delivery job for the same notification shouldn''t double-send.
Per-channel state. Track delivery per channel; partial-failure shouldn''t mean retry all.
Honor preferences at delivery time, not just creation. A user who turns off email mid-flight should stop getting emails for queued notifications.
Ban delivery to deleted users. Race: user deleted, notification created, delivery worker hits no-such-user.
No PII in the delivery queue. The notification ID is enough; the worker reads from DB.

Don''t:

Send the email inline in the request handler (slow; failure-prone)
Store rendered email content in the notification row (couples too tightly)
Ignore preferences at delivery time
Skip retry on failed deliveries

Output:

The creation function
The delivery worker code
The per-channel delivery functions
The retry / backoff policy
The idempotency key


The single biggest architectural win: **separating "event happened" from "deliver via channel X."** Adding Slack notifications becomes a new delivery function, not a touch-the-whole-system migration.

---

## 4. Batch Intelligently

A single user gets a flurry of notifications because someone went on a tagging spree. Don''t send 30 emails. Batch.

Design batching.

The patterns:

Pattern 1: Real-time send for instant; batch for digest

For each notification type, the user has an email_frequency:

instant: send each notification as it arrives
daily: collect all of this type; send one summary email per day
weekly: same, weekly
never: store in-app only

For "instant" types: deliver immediately. For "daily"/"weekly": insert into a digest queue; a scheduled job sends one summary email at the cadence.

Pattern 2: Burst-aware throttling

Even for "instant" types, if a user gets 20 notifications in 60 seconds, batch them:

Inside a 60-second window, accumulate notifications of the same type
Send a single email: "You have 20 new mentions. View them all here."
This handles bulk-tag scenarios gracefully

Implementation:

Lock-style window per (user, notification_type)
First notification in the window: schedule a batched-send job in 60 seconds
Subsequent notifications in the window: just attach to the existing batch
After 60 seconds: send one email summarizing all batch members

Pattern 3: Smart digests

Daily digests should:

Group by category
Show counts: "You have 12 new mentions, 3 task assignments, 7 comments"
Link directly to in-app feed for full detail
Not include the actual content (forces user to come back to the app)

Critical rules:

Burst throttling protects email reputation. 50 emails in 30 seconds to one address is spam-flag territory.
Digest content is a teaser, not full replacement. Goal is engagement, not replacement of the in-app experience.
Different types can have different cadences. "Workspace announcement" → weekly; "you''ve been mentioned" → instant.
Time-zone aware digests. Send daily digest at 9am the user''s local time, not server time.

Anti-patterns:

"Send each notification immediately" — fatigues users; creates spam reports
"Always batch" — defeats real-time use cases
"One global digest setting" — robs users of fine-grained control

Output:

The batching logic
The digest scheduler
The burst-throttling code
The time-zone-aware sending
The digest email templates


The single biggest reduction in notification fatigue: **burst throttling.** A user who gets bulk-tagged in 30 documents shouldn''t get 30 emails. One email "You have 30 new mentions" is the right answer.

---

## 5. Build the In-App Feed UI

Email is a delivery channel; the feed is where the notification system actually lives.

Design the in-app feed.

The pattern:

A bell icon in the app header with:

Badge showing unread count (capped at 99+)
Dropdown panel with recent notifications
"See all" link to a full /notifications page

The dropdown (recent 10-15 items):

Each item: actor avatar, type icon, type-specific copy, subject link, timestamp
Hover/focus highlights; click marks-read and navigates to subject
"Mark all read" button at top
"Notification preferences" link at bottom

The full page (/notifications or /inbox):

Tabs: All / Unread / Mentions / Activity / Archive
Same item rendering as dropdown
Bulk actions: mark read, archive, delete
Filtering by category, date range, actor

Rendering each item:

Use a type-specific renderer:

function renderNotification(n: Notification) {
  switch (n.type) {
    case 'comment.mention':
      return `${n.actor.name} mentioned you in ${n.data.documentTitle}`
    case 'task.assigned':
      return `${n.actor.name} assigned you "${n.data.taskTitle}"`
    case 'document.shared':
      return `${n.actor.name} shared ${n.data.documentTitle} with you`
    // ...
  }
}

Real-time updates:

When a new notification is created:

WebSocket / Server-Sent-Events push to user''s active session
Bell badge increments
Optionally: subtle toast pop ("New mention from Alice")
Clicking the toast opens the subject

Don''t:

Show full message bodies in the feed (privacy in shared screens; clutter)
Include marketing pushes alongside actual notifications (different categories)
Forget the empty state ("You''re all caught up — no new notifications")
Skip pagination on the full page (10K notifications won''t render)

Read state:

Mark-as-read on click of an item (or on subject view if you trust the navigation)
"Mark all read" button at the top
Read items still appear; just dimmer

Archive:

"Archive" hides from default views
Archived items still searchable on the Archive tab
Distinct from delete (which is rare and confirmation-heavy)

Output:

The bell-dropdown component
The full-page feed
The type-renderer registry
The real-time push integration
The bulk-actions logic


The biggest UX win: **a clear visual separation between "unread, important" and "read or low-priority."** Users scan; the bell badge tells them what to triage; the rest is history.

---

## 6. Per-User Preferences

Users hate being unable to control notifications. Give them granular control.

Design the preferences UI.

The pattern:

A settings page at /settings/notifications showing:

For each notification type, a row with:

Type name and description
Toggles for: In-app, Email, Push (where applicable)
Email frequency dropdown: Instant / Daily Digest / Weekly Digest / Off

Group by category:

"Mentions and direct interactions"
"Assignments and tasks"
"Comments and replies"
"Workspace activity"
"Marketing and product updates"

Quick-action buttons:

"Pause all notifications for 24 hours" (vacation mode)
"Reset to defaults"
"Mute this workspace" (for users in many workspaces)

Granularity layers:

Per notification type
Per channel (in-app / email / push)
Per workspace (in workspace settings; overrides global)
Globally on/off (top-of-page toggle)

The hierarchy: more-specific overrides more-general.

The preference-change flow:

Save on change (no "save settings" button needed)
Confirm visually ("Saved")
Take effect immediately (next notification respects new prefs)

Don''t:

Bury preferences 4 clicks deep (be findable)
Skip the unsubscribe link in emails (legal in EU; respectful elsewhere)
Force "all or nothing" (granularity is the point)
Override user choices for "important" notifications (legal mandates excepted)

The unsubscribe-from-email link:

Every notification email has a one-click unsubscribe (CAN-SPAM, GDPR). One click should:

Disable email for that specific notification type
NOT disable in-app delivery (different channel)
NOT mark them globally unsubscribed (granular)

Output:

The preferences UI
The preference-update API
The vacation-mode toggle
The per-workspace override
The unsubscribe-link handling


The single biggest user-trust signal: **a granular preferences page that respects user choices.** A user who turns off "comment.reply" emails and still gets them files an unsubscribe and writes you off.

---

## 7. Mobile Push (When You Have an App)

If you ship a mobile app, push notifications are a separate channel with their own rules.

Design the mobile push integration.

The pattern:

Token registration:

When the user installs the app and grants push permission:

App requests an APNs (iOS) or FCM (Android) token
App sends token to your backend: POST /api/push-tokens with { token, platform, app_version }
Backend stores per-user tokens

CREATE TABLE user_push_tokens (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  token TEXT NOT NULL UNIQUE,
  platform TEXT NOT NULL,       -- 'ios' | 'android'
  app_version TEXT,
  device_label TEXT,             -- "Alice''s iPhone"
  last_used_at TIMESTAMP,
  created_at TIMESTAMP NOT NULL DEFAULT NOW(),
  invalidated_at TIMESTAMP       -- set on uninstall / token rotation
);

Sending push:

Per push-eligible notification:

Look up active tokens for the recipient
Send via APNs / FCM (or use OneSignal, Knock, Courier as a unifier)
Handle token invalidation (token failed = uninstall; mark invalidated)

Rate limiting:

Cap push to 5/hour per user — push is the most invasive channel
Suppress duplicates within 5-minute windows
For digest-type cadences: skip push entirely; email/in-app is enough

Critical rules:

Respect OS-level "Do Not Disturb" — let the OS handle this; don''t override.
iOS notification provisional auth: be careful with iOS 12+ provisional permission; users can opt-out later.
Token invalidation: process feedback responses from APNs / FCM; remove dead tokens.
Payload size limits: APNs ~4KB, FCM ~4KB. Don''t exceed.
Quiet hours by user time zone: don''t push at 3am unless it''s actually urgent.

Don''t:

Push for low-signal notifications (you''ll lose the channel forever)
Skip the in-app representation (push is a teaser; the notification still needs an in-app row)
Treat push as more reliable than it is (delivery is best-effort)
Forget to handle push permission changes (user revokes → invalidate tokens)

Channel strategy:

A typical mature pattern:

High-signal, urgent: in-app + push + email
High-signal, non-urgent: in-app + email (no push)
Medium-signal: in-app + email digest
Low-signal: in-app only

Output:

The push-token registration endpoint
The token storage schema
The push-send code (per platform or via unifier)
The rate limiter
The quiet-hours / time-zone logic


The single biggest mistake with push: **using it for low-signal events.** A user who gets a push for a comment-reply will eventually disable push. Save it for "you have a meeting in 5 minutes" / "Alice mentioned you in a critical doc" — actually-urgent events.

---

## 8. Use a Notification Provider (Optional)

You can roll your own — many do — or use a service. Trade-off: build vs buy.

Decide build vs buy.

Notification providers (per Notification Providers):

Knock — modern API-first, multi-channel orchestration, preferences UI
Courier — workflow-builder approach, multi-channel
MagicBell — in-app feed widget + email + push
Novu — open-source notification orchestration
OneSignal — push-focused, free tier

They handle:

Channel orchestration (try push first; fall back to email if push fails)
Per-user preferences UI (drop-in component)
Template management
Delivery analytics
Multi-channel batching

Build when:

Your notification needs are simple (1-2 channels, <10 types)
You want full control over UI / UX
Cost is the primary constraint
Compliance (e.g., on-prem requirement) blocks SaaS

Buy when:

You''re shipping multi-channel (in-app + email + push + Slack)
You have 20+ notification types
You want preferences UX out of the box
Engineering time is more expensive than the SaaS bill

The hybrid pattern:

Many teams roll their own creation/storage but use a provider for delivery (especially mobile push and Slack). Best of both worlds.

For most indie SaaS in 2026:

DIY for the in-app feed and preferences
Use Knock or Courier when adding multi-channel orchestration
Or skip providers entirely until volume / complexity justify

Output:

The build-vs-buy decision with reasoning
The chosen provider (if buying)
The migration plan (if buying after building)


The biggest miscalculation: **building everything because "it''s just notifications."** Multi-channel orchestration, preferences UI, template versioning, deliverability tuning, and analytics are not trivial. Either keep DIY scope tight or buy the platform.

---

## 9. Audit and Monitor

Notifications are user-impact-heavy events. Audit and monitor.

Design audit and monitoring.

Audit events (per Audit Logs, selectively):

notification.preferences_updated — when users change their settings
notification.bulk_unsubscribed — when a user disables a category
notification.spam_complaint — when an email provider reports a complaint

(Don''t audit every notification creation — too noisy; sample if needed.)

Metrics:

notifications.created_count — by type, per minute
notifications.delivered_count — by channel
notifications.failed_count — by channel and reason
notifications.read_rate — % marked read within X hours
notifications.email_open_rate — by type (low rate = spammy type, candidates for default-off)
notifications.email_unsubscribe_rate — by type (>2% = noisy type, fix it)
notifications.push_dismissal_rate — by type
notifications.preferences.disabled_count — how many users disable each type

Alerts:

Email unsubscribe rate spike (notification type spamming)
Email spam-complaint rate >0.1% (deliverability disaster brewing)
Notification creation rate spike (possible bug or attack)
Mass-mute behavior (users disabling many types at once = product issue)

Per-type health dashboard:

Each notification type has metrics:

Volume per day
Read rate
Email open / click / unsubscribe rate
Push dismissal rate
User-initiated disable rate

Use this to spot noisy types and fix them.

Don''t:

Skip the unsubscribe-rate metric (it''s the canary)
Treat all notifications as equal in monitoring
Forget to alert on spam complaints

Output:

The metric emission
The alert rules
The per-type health dashboard
The runbook for "this notification type is spammy"


The single most-actionable signal: **per-type unsubscribe rate.** A type that gets >2% unsubscribe is broken; fix or kill. A type at 0.5% is doing its job.

---

## 10. Quarterly Noise Review

Notifications rot. Quarterly review keeps them tight.

The quarterly noise review.

Health check per type:

Volume trending up or down? Why?
Read rate steady or declining? (Declining = users tuning out)
Unsubscribe rate? Anything above 2%?
User complaints / support tickets mentioning it?

Decisions:

Keep / tweak (most types)
Default-off (high-noise types)
Combine (similar types could be one with metadata)
Kill (unused types)

New-type review:

Any product features added that should have notifications?
Any user-requested types?

Channel review:

Email open rate trends?
Push dismissal trends?
Are we using channels appropriately?

Preferences usage:

What % of users have customized preferences? (low = either defaults are right or feature is undiscoverable)
Which types are most frequently disabled? (signal for default-off candidates)

Output:

Top 3 noisy types to fix
1 type to kill
1 new type to add
1 default to flip


---

## What "Done" Looks Like

A working in-app notification system in 2026 has:

- A typed notification catalog with categories and conservative defaults
- First-class events stored in a notifications table with per-user state
- Decoupled creation and delivery (channel-agnostic creation; per-channel workers)
- Intelligent batching (instant + burst-throttled + digest cadences)
- Real-time in-app feed with unread badge
- Granular per-user, per-type, per-channel preferences with vacation mode
- Mobile push integration (where applicable) with rate limits and quiet hours
- Audit logs and per-type health metrics
- Quarterly review baked into the team rhythm
- Decision documented on build-vs-buy for orchestration

The hidden cost in notifications isn''t the SDK — it''s **noise that trains users to ignore the channel**. Once a user mutes everything, you can never get them back. Default to silent; require justification for each new notification type; kill noisy types ruthlessly. The discipline of "fewer, better notifications" outperforms any volume strategy.

---

## See Also

- [Multi-Tenant Data Isolation](multi-tenancy-chat.md) — workspace-scoped vs cross-workspace events
- [Roles & Permissions (RBAC)](roles-permissions-chat.md) — who sees what
- [Email Deliverability](email-deliverability-chat.md) — reputation matters for digests
- [Onboarding Email Sequence](onboarding-email-sequence-chat.md) — onboarding is a notification cadence
- [Activation Funnel](activation-funnel-chat.md) — notifications drive activation
- [Audit Logs](audit-logs-chat.md) — overlapping but distinct concept
- [Notification Providers](https://www.vibereference.com/backend-and-data/notification-providers) — Knock, Courier, MagicBell, Novu
- [Email Providers](https://www.vibereference.com/backend-and-data/email-providers) — transactional senders
- [Email Marketing Providers](https://www.vibereference.com/marketing-and-seo/email-marketing-providers) — distinct from transactional notifications
- [Background Jobs Providers](https://www.vibereference.com/backend-and-data/background-jobs-providers) — delivery workers run here

[⬅️ Growth Overview](README.md)