A message that reaches someone
without them opening the app first
Push notifications reach a user who is not currently looking at your app. They are also the fastest way to get muted or uninstalled if sent carelessly. We build the infrastructure around a simple discipline: fewer, better-targeted notifications beat a high-volume default that trains users to swipe them away unread. That means segmentation, scheduling and delivery tracking, not just a send button.
Who decides what gets sent, and when
Push notification infrastructure is the layer that decides who gets notified, when, and with what content. It also tracks whether the message actually reached someone and got opened. All of this sits on top of the underlying delivery services: Apple Push Notification service for iOS, Firebase Cloud Messaging for Android and web.
The delivery service alone just sends a message to a device token. The infrastructure around it is what makes that message relevant instead of noise.
When push actually earns its place
It earns its cost for any app or Mini App with a reason to reach a user who is not currently looking at it. Think a workout reminder, a game event, a price drop, an order update. A fitness app we built uses push to bring users back for scheduled workouts and coaching check-ins. The value is in reaching someone who stepped away.
It is the wrong tool, or at least wasted infrastructure, for an app with no genuine recurring reason to notify a user. Building segmentation and scheduling infrastructure for an app that sends one notification a month to everyone is more system than the use case needs. We would rather scope this down honestly than sell a full segmentation platform for a use case that needs three notification types.
What decides who gets which notification
We start from what the notifications are actually for. That determines the segmentation model. A reminder needs to know the recipient’s local time zone and preferred schedule. A game event needs to know who is actually in that game. A price alert needs to know who favorited that specific item. Building segmentation around real use cases, rather than a generic “send to all users” default, is most of what makes push notifications useful instead of annoying.
Delivery runs through Firebase Cloud Messaging and Apple Push Notification service, both free at normal volumes. Our infrastructure tracks delivery and open rates, so you can see which notifications actually get engagement and which get ignored or muted.
Scheduling respects the recipient’s local time zone by default. A notification sent at 3 a.m. because the server assumed everyone shares the backend’s time zone is a fast way to lose trust.
We build a send-volume guard as a structural part of the system, not a policy someone has to remember. It caps notifications per user per period, no matter how many separate features or triggers in the app want to send one. Without that cap, an app with five different teams each adding their own notification trigger will overload users, without anyone individually deciding to.
Opt-outs are enforced as a hard rule, checked before every send. They are logged so it is auditable, and never silently re-enabled by a new feature’s default settings.
How notification systems rot over time
The single biggest risk to a push notification system’s long-term value is volume creep. A reasonable notification rate at launch becomes five notifications a day eighteen months later, as more features add their own trigger. Users respond by disabling notifications entirely, which then silently breaks even the notifications that genuinely mattered.
We treat the volume guard as a permanent constraint, not a launch-day setting to be loosened later. Platform policy also shifts. Both Apple and Google have tightened rules around notification content and permission prompts over time. So we build against current guidelines, and plan for the prompt and permission flow to need occasional updates.
Price and timeline
| Option | Price | What it covers | Timeline |
|---|---|---|---|
| Core setup with segmentation | from $1,500 | iOS, Android and/or web push, basic segmentation, opt-outs | 1 to 2 weeks |
| Advanced system | from $3,500 | Scheduling by time zone, A/B tested send times, rich media | 2 to 3 weeks |
Running cost is close to zero, since both FCM and APNs are free at normal app volumes.
Related
This pairs with in-app subscriptions (App Store, Google Play) and deep links and app indexing so a notification opens directly to the relevant screen. See the development service page for our full build process. For a real example, see the fitness app’s coaching and reminder notifications.
Worried your notifications are already training users to swipe them away? Get in touch and we will look at your current send volume before adding anything new.
FAQ
How much does push notification infrastructure cost?
From $1,500 for setup across the platforms you need with basic segmentation and opt-out handling, 1 to 3 weeks. A system with advanced segmentation, A/B tested send times and rich media runs $3,000 to $6,000.
Which service do you use?
Firebase Cloud Messaging for Android and web push, Apple Push Notification service for iOS, both free at essentially any volume a normal app reaches. We build the segmentation, scheduling and tracking layer on top, since the raw delivery service alone does not give you any of that.
How do you avoid notification fatigue?
By building in a send-volume guard from day one. It caps how many notifications a user can receive in a given period, no matter how many separate triggers fire. And by segmenting, so a notification actually matches what that specific user cares about, rather than broadcasting one message to everyone. The cheapest way to lose a user's attention on this channel is sending them something irrelevant.
What about users who opt out?
Respected immediately and permanently as a hard rule in the system, not a preference that occasionally gets ignored by a new feature's code path. We log opt-outs so this is auditable, and treat a user who opted out as permanently excluded unless they explicitly opt back in.
Who owns the notification infrastructure?
You. The Firebase or APNs project, the segmentation logic and the delivery tracking live in your own accounts and repository. A dashboard or report shows what is actually being sent and how it performs.