How many of my users will actually receive a notification?

Fewer than your user count, always. Some never granted permission, some granted it and later turned it off, and both operating systems throttle or quietly group notifications from apps people ignore. We report the reachable number before the first send and again every month, including when it falls, because finding that out later would cost us your trust in every other number we give you.

Do I need a backend for this?

Something has to store device tokens against users and decide when to send. If you already have Firebase, Supabase or your own API, we use it. If you have nothing, that becomes part of the scope and is quoted as such — it is the single most common reason a push project costs more than the low end of the range.

Can my team send notifications afterwards without a developer?

Yes. OneSignal and the Firebase console both give a usable send interface, and we set up your segments and templates there as part of the work. A custom dashboard inside your own admin panel is a separate build with its own price, because it needs authentication, permissions and a send history of its own.

Why do you need changes made to my website?

Deep links only work if each platform can verify the app is allowed to handle your domain. Android checks a file at a fixed path under /.well-known/ on your site and iOS checks its own association file, both served over HTTPS as plain JSON with no redirect. If nobody can deploy those files, links will keep opening the browser instead of the app, so we confirm who owns that access in week one.

What happens if someone taps Do Not Allow?

On iOS that prompt is one-shot — the system will not show it again, and the only route back is the user turning notifications on in Settings. That is exactly why we put an explaining screen in front of the system prompt and only trigger the real one at a moment where the value is obvious. We also add a control in your app settings that deep-links straight into the OS settings page for people who change their mind.

Can this be tested before it goes live?

Partly, and it matters that you know where the limits are. Push does not work in Expo Go, so a development build is needed, and iOS notifications need a real device rather than a simulator. Deep links cannot be fully verified until the association files are live on your production domain. We schedule those dependencies early rather than discovering them in the final week.

Mobile & App Development

Push and engagement setup

Permission asked properly, deep links that land on the right screen, and the automated sequences that bring people back — the part clients are actually paying for.

From: $500–$3,000
Typical time: 1–3 weeks
Usually bought by: App owners

Installs are not users

An install is the moment a company stops paying to acquire someone and starts hoping. Someone opens the app once, gets interrupted, and never comes back. The app is on the phone, somewhere on page four, in a folder. The acquisition spend has already happened and it is quietly evaporating.

Push is the one mechanism that reaches back out of that folder, and unlike almost anything else in marketing its effect is directly measurable — sent, delivered, opened, action completed. That is why owners buy it, and it is also why it gets bought badly. The technical part, connecting an app to Firebase Cloud Messaging or OneSignal, is not the valuable part; it is plumbing and it takes a day or two. What you are actually paying for is the permission moment and the sequences, because those decide whether the pipe carries anything.

The permission moment is the hinge. Both platforms give an app exactly one system prompt, and on iOS a refusal is close to permanent — there is no second ask, only a settings screen nothing will ever prompt them to visit. An app that fires that prompt on first launch, before anyone knows what the app does, spends its one chance on a stranger. The fix is not clever code. It is a screen beforehand that says plainly what will be sent and why, shown at a point where the user already wants the thing being offered, followed by the real prompt only for people who say yes to that.

How the setup runs

Audit and plan the moments. What the app already has, where tokens could live, which points in the product justify a notification and which do not. The output is a written list of the messages that will exist, their trigger, their timing and their destination screen. One to two days.
Build the permission flow. A priming screen with real copy, placed at a moment of obvious value rather than at launch, then the system prompt. Android 13 and later requires a runtime notification permission that older Android never asked for, so both paths are handled explicitly. A refusal is handled gracefully — no nagging, and a control in settings that opens the OS notification page directly. Two to three days.
Wire the sending infrastructure. APNs key and configuration on the Apple side, Firebase Cloud Messaging or OneSignal on the other, device tokens stored against user records, and — the part usually skipped — the token lifecycle. What happens on logout, on reinstall, on a device being handed to someone else. Stale tokens are how one person ends up receiving another person's reminders. Two to four days.
Deep links, end to end. Association files deployed on your domain for both platforms, route handling in the app, and every notification carrying a destination. A tap on a booking reminder opens that booking, not the home screen. Deferred links, where someone installs the app first and should still land on the right page, need an extra service and are quoted separately. Two to four days.
The automated sequences. The actual product. Inactivity nudges, abandoned basket the following day, expiry warnings at seven, three and one day out, a reminder a couple of hours before a booking. Written as scheduled server-side jobs, with the time zone rule stated explicitly, because a renewal warning that fires at three in the morning does more harm than sending nothing. Three to five days.
Test on real devices, then hand over. Both platforms, physical handsets, foreground and background and app-killed states, plus a documented list of what your team can send themselves and how. One to two days.

What sets the number

$500–$3,000 for 1–3 weeks, and three things move a project across that span.

How many sequences, and how conditional they are. One inactivity reminder is an afternoon. Six sequences with entry and exit conditions, quiet hours, a frequency cap so one user cannot receive four messages in a day, and per-user time zones is a different piece of engineering.

Whether the app is ready to receive it. An app already running on a modern backend with user records and a session concept is straightforward. An app with no server-side scheduling at all needs that built before a single automated message can exist, and that is the most common reason a quote sits at the top of the range rather than the bottom.

Whether you want to send messages yourself. Using the OneSignal or Firebase console is included. A send interface inside your own admin, with segments, templates, permissions and history, is its own project and is priced on its own.

Where push setups go wrong

The permission prompt is fired on first launch. It is the default in every tutorial and it is the single most costly decision in this work. The prompt appears over a splash screen, before the app has demonstrated anything, and a large share of new users decline. On iOS that answer stands until they go into Settings themselves, which almost nobody does. Every sequence built afterwards is then working against an audience that was lost in the first four seconds of the app's life.

Someone promises you full reach. An owner with five thousand members hears that notifications will reach five thousand members. They will not. A portion never opted in, some revoked it later, and the operating system suppresses or summarises notifications from apps a person ignores. Saying that on day one, and putting the reachable number in the monthly report even when it drops, is the difference between trusting the reporting and concluding the work failed.

Notifications open the app, not the thing. A message about an expiring membership that dumps the user on the home screen has wasted the only attention it will ever get. This usually traces to deep links being treated as a final polish rather than a dependency — the association files never got deployed to your domain, or they were served with a redirect or the wrong content type and silently stopped verifying. It is invisible in testing on a developer build and obvious to every user on day one.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

How many of my users will actually receive a notification?: Fewer than your user count, always. Some never granted permission, some granted it and later turned it off, and both operating systems throttle or quietly group notifications from apps people ignore. We report the reachable number before the first send and again every month, including when it falls, because finding that out later would cost us your trust in every other number we give you.
Do I need a backend for this?: Something has to store device tokens against users and decide when to send. If you already have Firebase, Supabase or your own API, we use it. If you have nothing, that becomes part of the scope and is quoted as such — it is the single most common reason a push project costs more than the low end of the range.
Can my team send notifications afterwards without a developer?: Yes. OneSignal and the Firebase console both give a usable send interface, and we set up your segments and templates there as part of the work. A custom dashboard inside your own admin panel is a separate build with its own price, because it needs authentication, permissions and a send history of its own.
Why do you need changes made to my website?: Deep links only work if each platform can verify the app is allowed to handle your domain. Android checks a file at a fixed path under /.well-known/ on your site and iOS checks its own association file, both served over HTTPS as plain JSON with no redirect. If nobody can deploy those files, links will keep opening the browser instead of the app, so we confirm who owns that access in week one.
What happens if someone taps Do Not Allow?: On iOS that prompt is one-shot — the system will not show it again, and the only route back is the user turning notifications on in Settings. That is exactly why we put an explaining screen in front of the system prompt and only trigger the real one at a moment where the value is obvious. We also add a control in your app settings that deep-links straight into the OS settings page for people who change their mind.
Can this be tested before it goes live?: Partly, and it matters that you know where the limits are. Push does not work in Expo Go, so a development build is needed, and iOS notifications need a real device rather than a simulator. Deep links cannot be fully verified until the association files are live on your production domain. We schedule those dependencies early rather than discovering them in the final week.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Push & engagement setup All Mobile & App Development services