Why We Killed Our Mobile App. The $200k/year 'Presence' That Nobody Used.

We had a beautiful mobile app. Native iOS and Android. Push notifications. Offline sync. The works.

$200,000 per year to maintain. Two mobile engineers. App store compliance. Platform updates. Feature parity with web.

Our pride and joy.

Then I checked the numbers: 2,000 monthly active users.

We had 50,000 paying customers. 2,000 MAU on mobile. That's 4%.

When I asked users why they'd installed it, the honest answer wasn't "I need it." It was "I felt like I should. A professional tool should have an app, right?"

They installed it. They didn't use it.

We killed the app. Redirected users to the mobile-responsive web app. Support tickets dropped. Development velocity increased. Zero customer complaints.

Here's when mobile apps matter — and when they're expensive vanity projects.

Section 1: The "We Need a Mobile App" Fallacy

Somewhere along the way, "modern product" became synonymous with "has a mobile app."

The Conventional Wisdom:

"Users expect mobile apps. You need to be in their pocket. You need push notifications. You need app store presence."

This is true for some products. Instagram without a mobile app is incoherent. Uber without a mobile app is impossible.

But for B2B SaaS? For productivity tools? For dashboards and analytics? The calculus is very different.

The "Presence" Mentality:

Many companies build mobile apps not for utility, but for perception.

• "Competitors have apps, so we need one."
• "It looks more legitimate if we're in the App Store."
• "Enterprise buyers expect mobile apps on the feature list."

These are marketing reasons, not product reasons. The app exists to check a box, not to solve a user problem.

The Reality Check:

Ask yourself: When do your users actually use your product?

For our B2B tool, the answer was: At their desk. On their work computer. During work hours.

They weren't checking our product on the subway or in bed. They used it when they needed to do work — and that happened at a computer.

A mobile app for our use case was a solution to a problem that didn't exist.

Section 2: The True Cost of Mobile Apps

Mobile apps are expensive. More expensive than most companies realize.

Two Codebases:

Native apps mean maintaining two separate codebases: iOS (Swift) and Android (Kotlin).

Every feature must be built twice. Every bug might need to be fixed twice. Every design change must be implemented twice.

Cross-platform frameworks (React Native, Flutter) promise to help but introduce their own complexities. You're abstracting over two different platforms with different paradigms. The abstraction leaks.

Dedicated Mobile Engineers:

Mobile engineering is a specialization. Your web developers can't just "do mobile." You need specialists.

• iOS engineer: $150-200k/year fully loaded
• Android engineer: $150-200k/year fully loaded
• Mobile-focused QA: Part of someone's time, but real cost

That's $300-400k/year minimum in headcount for a "real" mobile team. For a small company, that's enormous.

Platform Complexity:

Mobile platforms are moving targets:

• App store review process: Updates delayed by days or weeks. Rejections require iteration.
• OS updates: When iOS 18 ships, you need to test and update. When Android 15 ships, same thing.
• Device fragmentation: Android especially has thousands of device/OS combinations.
• Platform policy changes: Apple and Google change rules. Suddenly your app needs modification.

The web is comparatively simple. Ship when you want. No review process. One codebase. Progressive enhancement handles device variety.

Feature Parity Pressure:

Once you have a mobile app, there's relentless pressure to maintain feature parity with web.

"Why can't I do X on mobile?" becomes a constant question. Every web feature triggers a mobile roadmap discussion.

You're now maintaining two products that must stay synchronized. Development velocity slows for both.

Section 3: When Mobile Apps Actually Matter

Mobile apps aren't useless. There are contexts where they're essential.

Consumer Apps with Frequent, Quick Interactions:

Social media, messaging, quick-reference utilities — products used multiple times per day for brief sessions.

These benefit from: App icon always visible. Instant launch. Push notifications that matter. Background sync.

Instagram, WhatsApp, Weather apps — mobile-native makes sense.

Offline Functionality Requirements:

Field workers who need access without connectivity. Healthcare providers in low-signal areas. Anyone working in environments where internet isn't reliable.

Native apps can store data locally and sync when connected. This is harder (not impossible) with web apps.

Deep Device Integration:

Products that need:

• Camera with processing (photo apps, document scanners)
• Sensor access (fitness apps, navigation)
• Background processing (music, podcasts)
• Always-on notifications that truly matter (messaging, on-call alerting)

Web can do some of this, but native access is superior.

B2B Rarely Meets These Criteria:

Most B2B SaaS products are used:

• At a desk (not on the go)
• With stable internet (not offline)
• For focused work sessions (not quick interactions)
• Without needing device sensors

A mobile-responsive web app serves these users perfectly. A native app is overhead without benefit.

Section 4: Our PWA/Responsive Web Alternative

When we killed the native app, we replaced it with nothing — because we already had something.

Mobile-Responsive Web App:

Our web app was already responsive. It worked on phones. It just wasn't marketed as "the mobile experience."

We made minor improvements:

• Touch-friendly button sizes
• Simplified mobile navigation
• Optimized for smaller screens

Development time: 2 weeks. Not the 12+ months the native apps had consumed.

Progressive Web App (PWA) Features:

We added PWA capabilities:

• Installable: Users can "Add to Home Screen." App icon on their phone.
• Offline support: Service workers cache critical assets. Basic functionality works without internet.
• Push notifications: Web push works on Android (iOS has limitations, but improving).

This gave users most of what they expected from an app — without the app.

The Results:

• Mobile usage: Stayed the same. The 4% who used mobile continued using mobile web.
• Support tickets: Dropped 30%. No more "app won't update" or "version mismatch" issues.
• Development velocity: Increased 25%. No more mobile feature parity discussions.
• Customer complaints: Zero. Literally zero customers complained about losing the native app.
• Cost savings: $200k/year in mobile team costs redirected to core product.

The native app was vanity. Killing it was liberation.

Conclusion

Mobile apps are a solution, not a requirement. Before you build one, ask: What problem does this solve that a mobile web app can't?

For B2B products, the answer is usually: Nothing.

Your customers don't want an app. They want their problem solved. If you can solve it on the web — which is everywhere, on every device, with no installation friction — you're serving them better than an app ever could.

Kill the vanity project. Ship the thing that matters.

Your customers don't want an app. They want their problem solved.