Push Notifications vs. Offline Mode: When You Can Only Build One

“We just lost another deal because we don’t have push notifications.”

As Senior Technical Mobile Product Manager at SugarCRM, I heard this from sales weekly. Our competitors had table-stakes features we were still debating. But the engineering reality was more complex than anyone in that room understood.

We had two critical mobile features blocking enterprise renewals. Both were urgent. Both addressed different user pain points. And we only had resources to build one.

This is the story of how I chose which fire to put out first—and why the answer wasn’t what stakeholders expected.

The Competitive Reality

Our mobile app ratings told the story: 4.2 stars on both App Store and Google Play. Not terrible, but not competitive. Salesforce and Zendesk were crushing us with 4.7+ ratings, and when we talked to churning customers, the feedback was consistent.

“We need our field reps to stay connected.”
“Sales managers can’t wait until reps get back to their desks to update records.”
“Why can’t I get notified when a lead is assigned to me?”

Push notifications were table stakes in the CRM mobile space. We knew it. Sales knew it. Our customers waiting on contract renewals knew it. We had multiple enterprise deals stalled specifically on mobile functionality gaps.

But we also had another critical problem: our field reps were seeing 5+ clients a day, back-to-back, often in areas with spotty connectivity. They couldn’t access customer data reliably or update records between meetings.

Both features were urgent. Both were blocking renewals. Both were necessary to remain competitive.

We could only build one.

The Core Platform Dependency

Here’s the problem that made everything worse: our core platform wasn’t ready.

SugarCRM’s notification system was built for web. When a record was assigned or someone was mentioned, the platform created a notification record that showed up in the web app’s notification center. But there was no event-driven architecture, no real-time processing pipeline, no API infrastructure designed for mobile push.

To build mobile push notifications, we needed:

• Core platform to emit events when notification-worthy actions occurred
• New APIs for mobile apps to register devices and manage preferences
• Database schema changes to support device tokens and delivery tracking
• Platform-level retry logic for handling delivery failures
• Infrastructure for queueing and rate limiting across potentially millions of devices

The core platform team was focused on their own roadmap—features that served the web application where most customers spent most of their time. Our organization’s priorities were heavily geared towards the web platform, making it difficult to secure resources for mobile-specific improvements.

Even if we wanted to build push notifications, we literally couldn’t. Not without the core platform team rebuilding significant portions of their notification infrastructure first.

The Data-Driven Approach

I needed to make a case based on evidence, not opinions. We established bi-monthly review sessions to identify known dependencies using qualitative and quantitative data from Splunk analytics, customer feedback, and app store reviews.

The data was clear: field reps needed to work disconnected. Push notifications were table stakes, but they required infrastructure we didn’t have. Leadership approved assembling a team of design, development, and architecture resources to initiate discovery, with a focus on short-term goals (offline mode) and long-term goals (push notifications).

The Decision

Push notifications required 4-6 months and resources we didn’t have. More critically, they required platform maturity we hadn’t built yet. The core platform team needed to rebuild their notification infrastructure before mobile could integrate.

The feature we could build within mobile’s control became the short-term priority. It addressed immediate field rep productivity while platform work proceeded in parallel.

I negotiated with product leadership to sequence the work: mobile delivers the short-term goal while core platform begins notification infrastructure. Push notifications would follow once the foundation existed.

The mobile team didn’t like waiting. Sales didn’t like explaining to prospects why we lacked table-stakes features. But the technical reality was clear—we needed to solve what we could control while building toward what we couldn’t.

The Outcome

The short-term feature shipped first, addressing field rep productivity issues. Customer feedback improved immediately, with reps able to work regardless of connectivity.

Push notifications followed several months later, with Sugar 11.1 and Sugar Mobile 33.0. Users could receive push notifications for record assignments and comment log mentions. We eventually expanded to more regions including Canada and Europe.

My tenure resulted in an increase in App Store and Google Play ratings from 4.2 to 4.8—not just from one feature, but from systematically addressing mobile-specific needs with the right sequence of features.

What I Learned About Push Notification Infrastructure

1. Platform maturity matters more than feature priority.
You can’t build push notifications on an architecture that doesn’t support them. Core platform capabilities—event processing, real-time APIs, device management—are prerequisites, not nice-to-haves.

2. Android delivery is a real problem with real costs.
40-70% undelivered notifications isn’t acceptable if notifications drive your retention strategy. Third-party services like MoEngage’s Push Amplification™ and CleverTap’s RenderMax solve this, but they cost real money. Factor that into your build-vs-buy analysis.

3. “Free” isn’t free.
Firebase Cloud Messaging is free with unlimited messages. But development time, maintenance burden, and analytics infrastructure aren’t. Most teams underestimate implementation by 3-5x.

4. Delivery guarantees don’t exist.
Both APNs and FCM can drop messages. Users might not receive notifications due to device state, OEM restrictions, or platform decisions. Build your retention strategy around this reality, not the ideal.

5. The decision isn’t features vs. features—it’s outcomes vs. outcomes.
Push notifications were important, but the short-term feature enabled field reps to do their jobs. When resources are constrained, choose the feature that unblocks core workflows over the feature that enhances communication.

The Build vs. Buy Decision

If I were making this decision today, I’d evaluate third-party services more seriously.

Direct integration with APNs/FCM:

• Pros: Zero per-message costs, complete control, no vendor dependency
• Cons: Months of development, ongoing maintenance, limited analytics, Android delivery problems

Third-party services (OneSignal, Airship, CleverTap):

• Pros: Weeks to integrate, rich analytics, solved Android delivery, A/B testing, segmentation
• Cons: Monthly costs, vendor lock-in, limited customization

For SugarCRM’s scale and constraints, a third-party service would have been faster. But we also needed platform-level notification infrastructure for other purposes. The investment in building it ourselves paid off in ways beyond mobile push.

Advice for Product Managers Facing This Decision

1. Understand the full technical scope.
Push notifications aren’t just an API integration. Map out device management, retry logic, analytics, segmentation, preference handling, and platform differences. Then triple your estimate.

2. Assess platform readiness.
Does your backend have real-time event processing? Device token storage? Rate limiting infrastructure? If not, you’re building platform capabilities first, mobile features second.

3. Validate actual user need.
Are push notifications blocking deals? Driving churn? Or are they “nice to have” features that don’t move retention metrics? Use data, not stakeholder opinions.

4. Consider Android delivery reality.
If Android represents 50%+ of your users, factor Android-specific delivery challenges into your strategy. This might justify third-party services even if you want to build infrastructure.

5. Sequence features strategically.
Sometimes the right answer is “not yet.” The short-term feature unblocked immediate user pain. Push notifications required platform maturity we hadn’t built. Sequencing mattered more than speed.

6. Communicate trade-offs clearly.
Stakeholders see features, not infrastructure. Help them understand that prioritizing one feature over another isn’t about importance—it’s about what’s technically feasible with current resources.

The Bottom Line

Push notification infrastructure looks simple from the outside. It’s not. The differences between APNs and FCM, the Android delivery crisis, the platform dependencies, the ongoing maintenance—these are real costs that affect product strategy, not just engineering timelines.

At SugarCRM, the decision to build the short-term feature first and push notifications second was the right call. Not because push notifications weren’t important, but because we couldn’t build them well with the resources and platform maturity we had. We could own the short-term solution. Push notifications required changes we couldn’t control.

Two years later, we had both. But the sequencing mattered. We solved the immediate problem (field rep productivity) before adding the enhancement (real-time notifications). Users forgave the delayed push notifications because the core mobile experience worked.

The lesson: Infrastructure decisions made in your first sprint affect your product for years. Choose based on technical reality and user outcomes, not feature urgency or competitive panic. Sometimes the best decision is the one nobody’s asking for—because it’s the one that makes everything else possible.

Push notifications weren’t just a feature we added—they were infrastructure we built after ensuring the foundation was solid. In product management, sequencing often matters more than speed.