Deciding between in-house push and a messaging tool

FCM and APNs are delivery infrastructure in their own right. Drop the SDK into the app, collect device tokens, call from your server, and the notification goes out. Plenty of services need nothing more. If the message is attached to a transaction — an order status, a booking confirmation — if the recipient is already fixed as the one party to that transaction, and if the send time is the moment the event happened, a tool has almost nothing to do on your behalf. Audience and timing are both decided inside your code. The same holds for the occasional broadcast notice. Add a tool in this range and the cost goes up while nothing else changes. The starting point is not a feature list but the nature of the messages you send today. This range rarely comes up in a sales conversation, because "keep your own implementation" runs against the other side's interest. Draw the line yourself before the evaluation starts.

The decision starts with counting. Split the notifications sent over the last three months into three kinds: transactional alerts, service notices, and marketing sends. For each kind, write down how many went out per month, who decided the audience, and who found out when a send failed. If the marketing column is empty and only the first two kinds are running, the current setup fits. If all three columns are full and the audience is decided by engineering every time, the table has already answered the question. Add one more line while you are there: the ratio of sends a person chose to make against sends an event produced automatically. When the first share is growing, that trend does not reverse.

The limit does not arrive as a capability gap. It shows up in how the work gets done. There are usually five signals. First, every send starts with an engineer writing a query to pull the recipient list. Second, nobody can say how many people the last send reached and how many tapped it. Third, the rules that keep messages out of the small hours and cap how many one person gets in a day are scattered across the code. Fourth, the team maintains its own handling for dead tokens and retries. Fifth, what began as push has grown into web push, email, and in-app messages. One signal on its own is still fixable. Three or more overlapping means the same request repeats next quarter in the same shape.

A token goes invalid when the app is deleted or left unopened for long enough, and a reinstall issues a new one. Leave the dead ones in place and your delivery rate drifts away from reality; with no routine that reads failure responses and clears them, that number stays inflated. When one person uses two or three devices, the same alert arrives two or three times. Without an identifier that groups subscriptions under a person, there is no place to stop the duplicate. How logout and account deletion affect a subscription, and where a user who declined permission is recorded, have to be settled in the same pass. On top of that sits the work of following operating system and store policy changes for notifications. None of this arrives as a feature request, so none of it lands on a schedule. That is why the real cost of the in-house path is always missing from the estimate for building it.

To send one campaign, someone hands over the audience conditions, waits for the list, checks the copy, and requests the send — and days pass before it goes out. Half the campaigns anyone planned never start because of those days. The real argument for buying a tool often lives here rather than in any feature. Yet nobody counts it, so it never reaches the approval document. Write down how many sends were requested last quarter, how many days each took from request to delivery, and how many were cancelled or missed their moment. That table is a better basis for the decision than a quote. If it turns out you request two or three sends a quarter, this is not the moment to buy anything. Lead time also does not vanish on its own once a tool is in place. If the data behind the segment a marketer wants has never been sent, the request goes back to engineering in front of the tool's own screen. So record, for each request, which missing data held it up.

The first is the billing unit. Counting active users and counting sent volume produce completely different numbers at the same scale. A service growing app installs and a service growing email volume are not looking at the same axis. The second is whether a segment can stand up at all. However good the tool, a condition cannot be built if user attributes and behavioural events never arrive. Half the adoption effort sits on the app and server side that sends this data, not on the tool. The third is the depth of automation. If entry conditions, waits, branches, and exit rules cannot be set from a screen, the marketer ends up calling the engineer again. The fourth is ownership of the account and the data. Confirm before signing whether the account is opened in your name and whether settings and experiment results remain after the contract ends.

FCM and APNs do not disappear when a tool is added. The tool is a layer that sits above them, and the platforms still do the delivery. So managing store certificates and sending credentials, deciding when and on which screen the app asks for permission, and designing the identifier that ties tokens to a person all remain your work. What the tool takes over is audience selection, send history, frequency and quiet-hour control, and channel expansion. Draw that boundary before adoption or the work you assumed the tool would do returns as a backlog item a few weeks later. The fastest way is to write the boundary into a sentence and have the vendor confirm it in the quote. Separate out which items need an app update in the same pass. If any of them wait on store review, the adoption schedule is tied to that cycle.

The first is tokens and consent. Whether the subscription data held by the existing SDK can be carried over intact, or whether users have to be asked for permission again, changes the switching cost several times over. The second is the send conditions running today. Rewriting conditions scattered through code as segments and triggers is a rebuild, not a transfer. It is common for this work to start while nobody knows the full list of what goes out under which condition. The third is deep links. The contract for where a tap lands, on a device with the app installed and on one without it, changes. The fourth is store certificates and sending credentials. Without knowing who holds the right to register these with the new tool, sending stops during the switchover week.

In-house sending and a tool are not an either-or. Keeping transactional alerts on your own server while moving only marketing sends to the tool is a common arrangement. It leaves one thing to decide: which side has the final say on consent and frequency limits. If both paths judge for themselves, alerts reach users who opted out and a one-a-day rule breaks at twice the rate. Put the decision in one place, have the other side ask it before sending, and the arrangement holds for years. Split channels along with paths. If both paths use the same channel, no report can say whose numbers these are.

Look at three things. First, whether the same firm handles both the tool contract and the implementation. A firm that only resells licenses steps back at SDK integration and event design; a firm that only implements cannot answer on plans and contract terms. Second, whether the scope states how far they touch your app and server code. If instrumenting events is not in the quote, that work comes back as an internal engineering commitment. Third, what remains when the project ends. The event and attribute definition sheet, the channel setup record, and campaigns that have actually been sent have to live inside your own account, or the next person buys the same work again. IXC works this range with one tool, OneSignal. Migration from a self-run FCM setup is inside our scope, and domestic contracting, KRW payment, and tax invoicing are handled through the same desk.