When developing mobile applications, push notifications always appear as an attractive feature. They seem like one of the most effective ways to communicate directly with users and draw them back into the app. My approach to this topic, especially in my own side projects or small client projects, has changed significantly over the years. What I initially deemed "absolutely essential" now makes me repeatedly ask, "Is it really necessary?"
In this post, I will explore the costs and benefits that push notifications bring, particularly in side projects and small-scale endeavors, based on my own experiences. I've found that beyond technical debt and operational burden, there's a delicate balance to strike in terms of user experience.
Push Notifications: Necessity or Luxury?
I've been developing my own mobile applications for a while; for instance, one of my side projects is an app that blocks Android spam calls, and another helps me with personal financial calculations. In both cases, user interaction was important. One of the first things I always thought was, "Let's add push notifications to keep users active." This is a common initial idea for many developers. However, fully understanding the true costs and operational burden behind this decision requires time and experience.
There's a big difference between a feature being on the "must-have" list and it truly being a "beneficial" feature. Push notifications, when used correctly, can add tremendous value. Delivering a timely, relevant, and personalized message to a user can increase an app's usage rates and engagement. However, the line for "correct use" is very fine. Notifications sent at the wrong time, irrelevant, or too frequently can have the opposite effect, alienating users from the app, or even causing them to turn off notifications entirely. This means all our effort goes to waste.
For me, the key question is: Does this notification represent real value in the user's life, or is it just a "don't forget me" message? Since resources are limited in side projects, the answer to this question is critical. If push notifications don't enhance the project's core benefit, they can become nothing more than a luxury, leaving you with development and operational costs.
Initial Cost and Setup Processes
Integrating push notifications into a mobile application required much more initial cost and time than I anticipated. It's not just about writing code; separate setups are needed for different platforms (Firebase Cloud Messaging - FCM for Android, Apple Push Notification Service - APNS for iOS). Even this first step represents a considerable effort, especially in my solo side projects.
ℹ️ Certificate and Key Management
On the APNS side, certificate and key management is quite detailed. You need to create certificates in
p8orp12format for both development and production environments, manage them through your Apple Developer account, and associate them with your app'sBundle ID. The slightest error in this process can result in notifications not being sent at all or only reaching specific devices. Similarly, for FCM, you need to create a Firebase project and add thegoogle-services.jsonfile to your Android project andGoogleService-Info.plistto your iOS project. Incorrect configuration of these files or missing SDK integrations are common issues preventing notifications from reaching devices.
I remember spending about 2 days on this initial setup phase when developing my Android spam app. I was working with Flutter, and while firebase_messaging package setup was relatively easy, making the necessary native authorizations and AndroidManifest.xml adjustments took my time. Especially on iOS, activating the Push Notification capability in the Capabilities section and linking the correct certificate can sometimes be frustrating. I encountered many cases where notifications worked in the test environment but not in production, usually due to certificate mismatches or incorrect APNS Auth Key usage.
<!-- Some necessary settings in AndroidManifest.xml (example) -->
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.myapp">
<uses-permission android:name="android.permission.INTERNET"/>
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>
<uses-permission android:name="android.permission.VIBRATE"/>
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
<application
android:name="${applicationName}"
android:icon="@mipmap/ic_launcher"
android:label="My App">
<!-- ... other activity and service definitions ... -->
<service
android:name="com.google.firebase.messaging.FirebaseMessagingService"
android:exported="false">
<intent-filter>
<action android:name="com.google.firebase.MESSAGING_EVENT" />
</intent-filter>
</service>
</application>
</manifest>
These initial costs are not limited to technical setup alone. Preparing development environments, testing on different devices, and troubleshooting potential issues also add up. If you're starting a mobile app project with the goal of "quickly getting an MVP out," including push notifications in the first version can significantly slow down this speed. In my experience, I've often thought that the time I spent managing this complexity would have been more beneficial if allocated to developing the core features of the application.
Operational Costs and Technical Debt
Setting up push notifications is just the beginning. The real costs and technical debt emerge from maintaining this system and ensuring it works correctly. Once integrated, regular maintenance and optimization requirements arise. This creates a significant burden, especially when I have limited time for side projects.
First, there's token management. To send a notification to a user's device, you need to obtain a "registration token" or "device token" for that device. These tokens can change over time, become invalid, or become obsolete if the user deletes the app. In one of my side projects, with a system of approximately 100,000 users, I observed that an average of 5% of tokens became invalid each month. If you don't regularly clean up these tokens, you'll attempt to send notifications to invalid targets, which consumes your API quota and occupies unnecessary server resources.
⚠️ Token Cleanup is Crucial
FCM and APNS services return an error when you try to send notifications to invalid tokens. It's vital to catch these errors and delete the corresponding tokens from your database. Otherwise, hundreds of thousands of "zombie tokens" can accumulate in your database. This situation can degrade notification sending performance and increase costs. I automate this cleanup with a
cronjob that runs nightly on my server.
Second, API call limits and server resources. When sending notifications to a large number of users, you need to pay attention to the API call limits of your service provider (FCM/APNS). For large-scale notifications, using batch sending mechanisms generally reduces the number of API calls. However, this also creates its own complexity: which notifications are prioritized, and which can be combined? In a notification sending service I wrote with FastAPI on my server, I observed CPU usage reaching 80% during sudden load spikes at certain hours. This meant either additional server capacity or more efficient code.
# Simple notification sending endpoint with FastAPI (example)
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from typing import List
from firebase_admin import credentials, messaging, initialize_app
# Initialize Firebase Admin SDK
cred = credentials.Certificate("path/to/your/firebase-adminsdk.json")
initialize_app(cred)
app = FastAPI()
class NotificationRequest(BaseModel):
tokens: List[str]
title: str
body: str
data: dict = {}
@app.post("/send-notifications")
async def send_notifications(request: NotificationRequest):
if not request.tokens:
raise HTTPException(status_code=400, detail="Tokens list cannot be empty.")
messages = [
messaging.Message(
token=token,
notification=messaging.Notification(
title=request.title,
body=request.body,
),
data=request.data,
)
for token in request.tokens
]
try:
# Send notifications in a batch
batch_response = messaging.send_all(messages)
print(f"{batch_response.success_count} messages were sent successfully")
if batch_response.failure_count > 0:
for response in batch_response.responses:
if not response.success:
print(f"Failed to send message: {response.exception}")
return {"status": "success", "sent_count": batch_response.success_count, "failed_count": batch_response.failure_count}
except Exception as e:
raise HTTPException(status_code=500, detail=str(e))
Finally, error management and observability. Why didn't the notifications go through? Which device didn't receive them? Did the user not see it, or did it never arrive? To answer these questions, I have to set up comprehensive logging and monitoring systems. Recording every notification sending attempt, its success/failure, and the reason facilitates troubleshooting. In a production ERP system, when we noticed that late shipment alerts were sometimes delayed, by examining the notification service logs, I identified queue buildups caused by database slowdowns, especially at month-ends. This became a critical lesson not just for push notifications, but for general system management.
User Experience and Interaction: Where is the Real Benefit?
The biggest promise of push notifications is to increase user engagement. However, the fulfillment of this promise depends on the content, timing, and frequency of the notification. When used incorrectly, notifications can become a source of annoyance rather than a benefit. My observation is that most side projects struggle to strike this balance.
In my task management app, I used push notifications to send reminders to users. Notifications like "Did you forget to complete your task?" had click-through rates of around 20%, meaning one in five people clicked the notification and opened the app. This is a pretty good rate. However, general announcement notifications like "New features added!" or "Our blog post is published!" had click-through rates below 5%. This clearly showed that notifications need to be personalized and tailored to the user's immediate needs.
💡 Personalization and Context
What makes a notification valuable is how relevant it is to the user's current context. Personalizing notifications using data such as the user's last activity, preferences, or even location can significantly increase engagement rates. Instead of "Product X is back in stock!", a notification like "Your favorite product X is back in stock with a special discount just for you!" is much more engaging. In my financial calculators side project, personalized reminders I sent close to payment due dates set by users were very effective in increasing daily app usage.
Sending too many notifications leads to "notification fatigue." When a user receives dozens of notifications from several different apps daily, they eventually start ignoring all of them. In this case, your app's notification also gets lost among the others. Users might even completely turn off notifications for your app, which means losing one of your communication channels entirely. While working on an internal platform for a bank, we observed that users complained about irrelevant system alerts, and many had turned off notifications. This is not just a technical problem, but also an issue related to user experience and product strategy.
At this point, defining a notification strategy is critical. What types of events require notifications? How often should they be sent? When would the user want to see this notification? The answers to these questions can be found through simple A/B tests or by monitoring app usage metrics. In my side projects, I only send push notifications when the user has an active expectation from the app (e.g., when a task is due) or when there's a truly important development. This approach both reduces costs and increases the value of the notifications.
Alternatives and Smarter Approaches
Given the costs and potential negative impacts of push notifications, I've realized they're not always the only solution. Especially in side projects, there are less costly and more controlled communication channels or strategies available. Sometimes, instead of using the "coolest" technology, choosing the most appropriate and sustainable one for the purpose is smarter.
In-app notifications are a great alternative to push notifications. These notifications, which the user sees when they open the app, usually indicated by a bell icon, are a way to convey information without disturbing the user. Their cost is almost zero because they don't require an external service or API call; the app simply fetches and displays the data internally. In my task management app, I chose to deliver less critical announcements and general information through in-app notifications. This reduced my push notification traffic by 40% and prevented notification fatigue.
ℹ️ Pull-Based Systems
While push notifications work on a "push" mechanism, in-app notifications generally work on a "pull" mechanism. That is, when the user opens the app, the app pulls new notifications from the server. This model protects the server load from sudden notification storms and ensures the user receives information only when relevant. Specifically, in an ERP for a manufacturing company, we used web sockets or in-app pull mechanisms instead of push for real-time production information on operator screens. This way, we maintained data consistency even during momentary network disconnections.
Email and SMS are still powerful communication channels. Especially for critical and urgent situations, SMS is a method with high open rates. However, the cost of SMS is much higher than push notifications, and there's also a risk of being perceived as spam. Email, on the other hand, is ideal for less urgent situations, conveying detailed information, or sending summary reports. In one of my client projects, we used a combination of SMS and email for order confirmations and shipping information for an e-commerce site. Mobile app notifications were reserved only for abandoned cart reminders or personalized discounts. This optimized costs and made the communication strategy more flexible.
In some cases, web push APIs can also be an alternative. If your side project has a web interface, browser-based push notifications offer a way to reach users without developing a mobile app. Setup is relatively easier, and costs are generally lower. However, since it depends on the browser and user permissions, it might not be as reliable as mobile app notifications.
In summary, every communication channel has its own advantages and disadvantages. The important thing is to find the most suitable combination for the project's needs, budget, and target audience. In my experience, starting with simpler and more controllable methods and then moving to push notifications when truly needed has been the most sensible approach.
My Approach: A Pragmatic Balance
With the experience I've gained over the years, my approach to push notifications has become quite pragmatic. I no longer have a preconceived notion that "push notifications must be included" in every side project or project. On the contrary, I now evaluate all the costs and potential benefits of adding this feature in much greater detail.
Generally, when starting a side project, I don't include push notifications in the initial MVP (Minimum Viable Product) scope. I establish the core functionality and observe whether the app is adopted by users. If a real need arises and user feedback indicates that push notifications would enhance the app's value, then I delve into the topic. This approach prevents me from expending unnecessary effort and allows me to direct my resources to more critical areas. For example, in my Android spam app, I postponed this feature until users requested instant notifications for specific call types. This allowed me to focus solely on the core blocking logic for the first 3 months.
I also make some optimizations to reduce costs. First, I only send truly critical and time-sensitive notifications as push notifications. For other, less urgent information, I prefer in-app notifications or email. This significantly reduces my notification traffic and, consequently, my API usage costs. In my financial calculators, I designed monthly payment reminders to be sent only if the user explicitly requested them and a maximum of once a day. This reduced my notification costs by 80% and eliminated user complaints.
🔥 Cost Trap: Unnecessary Notifications
Every notification is a cost, not just in terms of money, but also in developer time and operational burden. In client projects or my own products, I often encounter the tendency to say, "Let's send this as a notification too." This can lead to an uncontrollable flood of notifications and high costs over time. I question every notification request with, "What value does this notification add to the user?" and "Is there an alternative to this?"
Additionally, I compare different service providers or open-source solutions. There have been times when I built my own notification queues using simpler messaging systems like Redis Pub/Sub. While this means sacrificing some conveniences offered by services like FCM/APNS, it provides full control and potential cost savings. Of course, this comes with increased development and maintenance overhead, so I always perform a trade-off analysis when making this decision. I experienced a similar trade-off during a VPS migration process; should I build my own solution or use a managed service? In both cases, balancing cost and flexibility is essential.
In conclusion, for me, push notifications are no longer a "default feature" but a tool that requires careful consideration and a strategic decision. When trying to create the best impact with limited resources, as is inherent in side projects, establishing this balance correctly is crucial.
Conclusion: A Smart Notification Strategy for Side Projects
Mobile push notifications are a powerful tool that, when used correctly, can significantly increase user engagement and app value. However, especially for those like me who work on side projects or develop small-scale projects, it's crucial to carefully evaluate the initial and operational costs, the technical debt they bring, and risks like user fatigue. In my experience, instead of always rushing to the "coolest" or most commonly used solution, determining the most suitable strategy for the project's actual needs and budget has been much smarter.
Before integrating push notifications into a side project, the fundamental questions I ask myself are:
- Does this notification solve a real problem in the user's life, or is it just trying to grab attention?
- Are the costs of sending this notification (development time, server resources, API fees) greater than the benefits it will provide?
- Is there a simpler, less costly, or more controlled way to achieve this communication (in-app notification, email, SMS)?
- Do the notifications enrich the user experience, or do they carry the risk of causing notification fatigue?
The answers to these questions usually lead me to a more minimalist and focused notification strategy. In side projects, the goal is to create maximum impact with limited resources. This often means adding only the most critical and valuable features, not every feature.
In my future side projects or projects where I provide consultancy, I will always evaluate push notifications from this perspective. First the problem, then the solution. First the cost-benefit analysis, then the integration. This approach has been a critical lesson for both my sustainability and the sustainability of the products I develop.
