Solfreaks RetainLoop covers everything an app says to a user after the install: push notifications, in-app messages, and email or WhatsApp follow-ups, all planned around what people actually do inside the product.
Many apps ask for notification permission on first launch and then send the same promotion to everyone at nine in the morning. Plenty of users switch them off soon after. We build fewer messages, send them at better moments and check whether the people who receive them really do come back more often than the people who don't.
What we'd put in place
- Push delivery. Firebase Cloud Messaging for Android and Apple Push Notification service for iOS, connected to your backend and API or to a tool such as Firebase, OneSignal or Braze.
- A permission flow. A short screen of our own, shown just after the user has got something out of the app, ahead of the system prompt.
- Onboarding messages. A small sequence across the first week that points people to the one action which predicts they'll stay, found by looking at your own data.
- Segments and triggers. Messages fired by behaviour, such as an abandoned basket, an unfinished lesson or a subscription about to lapse, rather than by the calendar.
- Frequency caps and quiet hours. Per-user limits in the user's own time zone, so nobody gets six messages in one evening.
- Win-back flows. A few messages to lapsed users that stop automatically after a set number of attempts.
Why most notification programmes backfire
The most common mistake is blasting every user with the same message. A close second is asking for permission before the user knows why they would want it; on iOS you effectively get one chance at the system prompt, and Android 13 and later makes apps ask too. Then there is the habit of never measuring opt-outs, so the damage stays invisible until a large share of your audience can no longer be reached.
Delivery has its own problems. Some Android manufacturers kill background apps aggressively, so notifications arrive late or not at all. We test on real, cheaper handsets for exactly this reason, and we tell you plainly what can and can't be fixed.
How a rollout runs
- Audit. We look at what you send now, your opt-in and opt-out rates and where users drop off. This usually takes one to two weeks.
- Moment map. Together we decide which moments in the app deserve a message and which are better left alone.
- Build and device testing. Templates, triggers and caps go in, and we check delivery on real iPhones and a spread of Android handsets. Expect two to three weeks.
- Staged launch. The first messages go to a slice of users, and a holdout group is left alone so we have something to compare against.
- Read and adjust. After a few weeks of cohorts we compare retention, opt-outs and revenue, and cut whatever isn't earning its place. This relies on clean app analytics, and if yours are messy we fix them first.
Who this helps, and who it doesn't
It works for apps with a reason to come back more than once: shopping, learning, fitness, booking, delivery, anything with subscriptions or repeat orders. If you already have a healthy number of installs and a sense that most people open the app twice and vanish, this is worth doing.
Skip it if the app is a one-off utility. Notifications can't invent a reason to reopen something that offers nothing to return to, so fix the product first. It's also overkill with a few dozen users; talk to them directly instead. We'll decline briefs that amount to daily promotions to everyone.
One boundary: marketing email and WhatsApp messages need consent, and the rules differ by country. We build the opt-in and unsubscribe handling, but we build software and can't give legal advice. For the WhatsApp side in more depth, see our WhatsApp business automation work.
What moves the retention price
Price follows scope. The main drivers are how many channels you want (push alone, or email and WhatsApp as well), how many message flows we design, whether your backend has to be changed to send the right events, and how many A/B tests you want running. Tools such as OneSignal or Braze bill you separately, and some price by user count. We can do a fixed-scope setup for a defined set of flows, then a monthly plan to manage and test, or go straight to monthly work.
First flows are typically live in three to five weeks. A fair read on retention takes a couple of months, because it needs several cohorts. The quote follows a short discovery call.
Why Solfreaks for retention work
Notifications sit between code and store rules, and we work on both: we're a Rawalpindi software house with apps published on Google Play. The team is small and you speak to the people building your flows. The Firebase project, tool accounts and message data are in your name from the start. Tell us about your app and where users drop off, and we'll suggest where to begin.
Open-source tools and references
A few public projects that come up a lot in this kind of work. They belong to other people and teams. We link to them because they are worth a look, not because anyone pays us to.
- firebase/quickstart-androidOfficial Firebase samples for Android, including messaging.
- OneSignal/OneSignal-Android-SDKOneSignal's Android SDK for push and in-app messages.
- braze-inc/braze-android-sdkBraze's Android SDK.
Frequently asked questions
When should the app ask for notification permission?
After the user has seen some value, not at first launch. A good moment is right after they place an order, save something or finish a lesson, with a screen of our own explaining what they'll receive. On iOS a refusal at the system prompt can't be undone from inside the app, so we don't waste that one chance. Android 13 and later asks at runtime too.
How many notifications a week is too many?
There's no universal number. A delivery app can send several in a day because each one is useful; a utility might manage one a month. We start low, cap every user, and watch opt-outs and uninstalls next to open rates. If a message type raises opens but also pushes more people to switch notifications off, it costs more than it earns and gets cut.
Do we need Braze or OneSignal, or is Firebase enough?
For many apps Firebase Cloud Messaging with Firebase's own tools is enough and costs less. OneSignal suits non-technical teams who want to edit campaigns themselves. Braze and similar platforms make sense when you run many channels and segments at scale and have someone to operate them. We'll recommend the simplest option that fits, not the one with the longest feature list.
How do you know the messages improved retention?
By keeping a small holdout group that receives nothing and comparing it with everyone else over the same weeks. Open rates alone mislead, because people open messages they would have acted on anyway. We look at day-7 and day-30 retention, opt-outs and, for paid products, renewals. Small user bases need longer for a clear answer, and we'll say when the numbers are too thin to trust.
Some Android users say they never get our notifications. Can you fix that?
Partly. Several phone makers add battery optimisation that stops background apps and delays messages, and some users have simply turned permission off. We set message priority correctly, avoid delivery patterns that get throttled, test on real handsets, and add an in-app message or a short help page for affected users. We can't override a manufacturer's battery rules, and we won't claim otherwise.
Talk it through with us
Tell us what you are building and where it hurts. You get a straight answer, a plan and a price, and if we are not the right people we will say so.
