In-app notifications keep users informed without leaving the product.
Email works for async communication. In-app notifications handle real-time: 'Someone commented on your document', 'Your export is ready', 'New message from a team member'. The notification bell, unread count, and notification feed are standard SaaS UI patterns with specific implementation requirements.
No in-app notification system — users miss important events or the product feels unresponsive to activity because nothing surfaces inside the UI
In-app notification systems have three layers:
The data model:
notifications {
id
recipient_user_id
type (comment | mention | export_ready | payment_failed)
title
body
read_at: timestamp (null = unread)
action_url (where to navigate when clicked)
created_at
}
Notification creation:
Generated by application events. A comment creates a notification for the mentioned user. An export job completing creates a notification for the requesting user. Background job or synchronous action writes to the notifications table.
Delivery to the UI:
Option 1: Polling. The frontend polls /api/notifications?unread=true every 30 seconds. Simple to implement; not real-time; adds server load.
Option 2: WebSockets. Open a persistent connection; server pushes new notifications instantly. Best user experience; requires WebSocket infrastructure (Pusher, Ably, or a custom WebSocket server).
Option 3: Server-Sent Events (SSE). One-directional push from server to client. Simpler than WebSockets for notification use cases. Works with serverless via Vercel's streaming support.
The notification bell UI:
- Badge with unread count
- Dropdown feed of recent notifications
- Mark as read (individual and "mark all as read")
- Click navigates to the relevant location in the app
Notification preferences: Users should be able to opt out of specific notification types. Store preferences in the database; check before creating notifications.
In-app notification system with a notification feed, unread count, real-time delivery, and notification preferences
Notifications table
with appropriate schema
Notification creation
triggered by application events
Real-time delivery
(polling for simple; SSE/WebSocket for real-time)
Notification bell and feed
UI component
Mark as read
actions and unread count
One honest number to start.
Fixed-scope, fixed-price. The number below is the starting point — final scope is built from your brief.
In-app notification system with a notification feed, unread count, real-time delivery, and notification preferences
Three steps, every time.
The same repeatable engagement on every project. No surprises, no mystery, no billable ambiguity.
Brief & discovery.
We send you questions, then get on a call. Output: a written scope with every step, feature, and integration listed.
Build & ship.
Fixed schedule, weekly reviews. No scope creep unless you change the scope — and if you do, we reprice it transparently.
Warranty & retainer.
30-day warranty on every launch. Most clients stay on a monthly retainer for ongoing features and maintenance.
Why Fixed-Price Matters Here
Notification scope is defined by the notification types and delivery requirements. Fixed-price from the event list.
Questions, answered.
For complex multi-channel notification management (in-app + email + push + Slack), a service like Knock or Novu saves significant development time. For in-app notifications only, building directly is straightforward.
Keep the last 90-180 days and paginate the notification feed. Archive older notifications rather than deleting them (useful for audit purposes).
Tell Ryel about your project.
Describe what you’re building and what outcome you need. You’ll have a written, fixed-price scope within the week.