PWAs in 2026: Our B2B SaaS Ditched Native Apps - Here's What Happened

General
1

This might be controversial, but I want to share a decision we made at our B2B fintech SaaS that went against conventional wisdom: we sunset our iOS and Android native apps in favor of a Progressive Web App (PWA).

18 months later, here’s the honest retrospective.

The Context

  • Series B fintech startup, ~250 enterprise customers
  • Customer base: 70% mobile users, 30% desktop
  • Problem: Maintaining web, iOS, and Android codebases was killing our velocity
  • Small team: 15 engineers total, 5 dedicated to mobile

Why We Considered It

The typical reasons:

  • Cost: Three separate codebases for essentially the same features
  • Velocity: Features taking 3x longer to ship across all platforms
  • App store friction: Update approval times, 30% commission, discovery challenges

But the real trigger was Safari finally supporting service workers universally in 2026. That was the last major holdout that made PWAs viable.

The Business Case

Here’s what made it compelling:

Cost Savings

  • PWAs cost 33-50% less to build than native (our experience validated this)
  • No app store 30% commission (we have in-app purchases)
  • Eliminated app store fees and approval processes

Distribution Benefits

  • Users find us via Google search, not just app stores
  • No install friction - instant access from any device
  • Updates are instant, no waiting for app store approval

Engineering Velocity

  • One codebase instead of three
  • Ship features once, available everywhere immediately
  • Faster iteration cycles

The Migration

  • Timeline: 4 months from decision to sunset
  • Stack: Next.js, Workbox for service worker, modern Web APIs
  • Strategy: Announced 6 months in advance, gave users time to transition

The Results (Real Numbers)

User Adoption

  • 15% drop in “app installs” (obviously, no app to install)
  • 40% increase in daily active users (web access removed friction)
  • Higher engagement from users who never installed the app

Engineering Velocity

  • Feature ship time decreased by 60%
  • Bug fix cycle from 1-2 weeks (app store approval) to same-day

Customer Acquisition

  • CAC decreased by 25% (search traffic, no app store competition)
  • Trial-to-paid conversion up 18% (lower friction to try)

The Tech That Works

  • Push notifications: Work on all platforms now
  • Offline mode: Service workers are solid, app works offline for weeks
  • Install prompt: “Add to Home Screen” has decent adoption
  • Background sync: Works well for our use case

The Tech That Still Lags

  • iOS storage limits: Still more restrictive than native
  • No background processing: Can’t run tasks when app is closed
  • Some APIs still missing: Bluetooth, NFC, advanced camera features (we don’t need them)
  • iOS install UX: Still clunkier than Android

Customer Feedback (Mixed)

Power Users
Initial complaints: “This feels slower” (it wasn’t), “I miss the app icon” (they can add to home screen), “This isn’t as smooth” (subjective)

After 3 months: Most adapted, some still prefer native

Casual Users
Overwhelmingly positive: No install required, works on any device, always up-to-date

IT/Security Teams
Mixed: Some love that there’s no app to approve/deploy. Others concerned about browser security model vs app sandboxing.

What We’d Do Differently

Communication
We underestimated how attached some users were to having an “app.” Should have communicated benefits better and earlier.

Progressive Enhancement
Should have launched PWA alongside native apps for 6 months, let users choose, sunset based on usage data.

Feature Parity
We launched PWA before achieving 100% feature parity. That was a mistake. Some power users lost features temporarily.

Would We Do It Again?

Yes, absolutely. But with caveats:

PWAs make sense if:

  • Your app is primarily CRUD/content, not platform-intensive
  • Your users access from varied devices/locations
  • Engineering velocity and iteration speed matter more than platform integration
  • You can accept slightly lower engagement from power users for broader reach

PWAs don’t make sense if:

  • You need deep platform integration (background GPS, payment systems, advanced hardware)
  • Your users demand native polish and performance
  • App store discovery is crucial for customer acquisition
  • You have resources to maintain separate platforms well

The ROI

  • Engineering velocity: Up 60%
  • Operational cost: Down 40%
  • Customer acquisition cost: Down 25%
  • Daily active users: Up 40%
  • Power user satisfaction: Down ~10% initially, recovered to neutral

From a business perspective, it was the right call for us.

Questions for the Community

  1. Has anyone else made this transition? How did it go?
  2. For those building PWAs, what’s your offline/sync strategy?
  3. Anyone regret moving away from native?

Happy to answer questions about our implementation or decision process.

  • David
2

David, I have to respectfully push back on some of this from a mobile engineering perspective. PWAs have their place, but they’re not a silver bullet, and for certain use cases, native is still clearly superior.

Where I Agree

Your results are impressive and I don’t doubt them for your specific use case. For a B2B SaaS CRUD app, PWAs can absolutely work. The engineering velocity gains and cost savings are real.

Where PWAs Still Fall Short

But let me be clear about the technical limitations that make PWAs a non-starter for apps like Uber:

Deep Platform Integration

  • GPS background tracking (ride tracking requires this)
  • Payment processing with platform-specific security
  • Camera APIs for document scanning, ID verification
  • Push notification reliability (life-critical for rider/driver matching)
  • Bluetooth for IoT integration
  • Native platform services (Apple Pay, Google Pay integration)

Performance Reality
For complex, interaction-heavy apps, native is still meaningfully smoother. We’re not talking benchmarks - I’m talking about the feel of scroll physics, gesture handling, and animation fluidity that users viscerally notice.

The Emerging Markets Angle

Here’s something interesting though: In bandwidth-constrained markets, PWAs can actually be superior to native apps.

In São Paulo, we’ve tested PWAs extensively:

Advantages:

  • No 100MB+ download required
  • Works progressively as assets load
  • Users can access immediately
  • Lower data consumption overall

But in those same markets:

  • Offline capability becomes critical
  • Device performance is lower
  • Browser consistency is worse

The Right Use Cases

PWAs make sense for:

  • Content and CRUD applications (your fintech case)
  • B2B tools where users access from varied devices
  • Apps where instant updates matter more than platform integration
  • Markets where app install friction is high

Native makes sense for:

  • Apps requiring platform-intensive features
  • Consumer apps where polish and performance differentiate
  • Apps with complex real-time interactions
  • When app store distribution is valuable

The Question I Have

How did you handle offline data sync complexity?

This is always the hardest part of PWAs. With service workers, you can cache assets. But complex offline data sync with conflict resolution, queued operations, and optimistic updates - that’s gnarly.

Did you build custom sync logic? Use a library? What’s your architecture for ensuring data consistency when users go offline mid-operation?

Also curious: What percentage of your users actually “install” (add to home screen) vs just bookmark/access via browser?

Bottom Line

I’m glad PWAs worked for your use case. They’re definitely getting better and 2026 is the best year yet for web capabilities.

But they’re not a replacement for native apps across the board. They’re another tool in the toolkit, and choosing the right tool depends on your specific requirements.

For apps that can work within PWA constraints, the velocity and cost benefits you’re seeing are compelling. For apps that need what native provides, those constraints are dealbreakers.

  • Maria
3

Really interesting case study, David. I’m building a developer tools platform and we’re actively considering PWA vs native right now.

My Context

Building tools for developers - think code editors, debugging tools, terminal access, that kind of thing. Developer tools have some unique requirements.

The PWA Questions

Debugging Experience
How’s the debugging experience for PWAs compared to native apps? Developer tools need excellent DevTools, performance profiling, and debugging capabilities. Does the browser DevTools ecosystem work well enough, or do you miss native debugging tools?

System-Level Access
Developer tools often need file system access, process management, environment variables, etc. I know some of this is coming to the web platform, but how are the limits in practice?

Performance
For CPU-intensive operations (code parsing, linting, compilation preview), does the browser JavaScript engine perform well enough compared to native?

What I’m Leaning Toward

Your velocity and cost arguments are super compelling. Single codebase, instant updates, works everywhere - that’s the dream for a small team.

But I’m worried about:

  • File system access limitations
  • Performance for heavy operations
  • Offline functionality for code editing
  • Terminal/shell integration

Specific Technical Questions

  1. Framework/Tooling: What PWA framework did your team use? Next.js with Workbox? Something else?

  2. Caching Strategy: How do you handle cache invalidation and updates? Do users ever get stuck on old versions?

  3. Authentication: How do you handle secure auth tokens in a PWA vs native keychain?

  4. Performance Monitoring: What tools do you use to track PWA performance in the wild?

Maria’s point about offline sync is exactly what I’m worried about. Our tool needs to work offline and sync complex state when back online.

Would love more technical details about your implementation!

  • Alex
4

David, from a design systems perspective, the single-codebase story is incredibly appealing. Let me share the design angle on PWA vs native.

The Design System Dream

Single Design System
This is huge: One design system, one component library, works everywhere. No more:

  • iOS version of button component
  • Android version with material design
  • Web version with different interactions

PWA means: Build it once, it works everywhere. That’s a designer’s dream.

The Platform UX Challenges

But here’s where it gets tricky: How do you handle platform-specific design paradigms in a PWA?

Users have expectations based on their platform:

  • iOS users: Expect swipe-back gestures, bottom tab bars, specific modal presentations
  • Android users: Expect hardware back button, material design patterns, floating action buttons
  • Desktop users: Expect hover states, keyboard shortcuts, different information density

Can you make a PWA feel native to each platform, or do you embrace a platform-agnostic design language?

Our Experience

We’re building a design system that targets web, React Native, and we’re evaluating PWA for a product.

What Works:

  • Design tokens (colors, spacing, typography) translate perfectly to PWA
  • Component APIs can be consistent
  • Responsive design patterns are mature

What’s Hard:

  • Platform-specific interactions (gestures, navigation patterns)
  • Making it feel “native” vs “web”
  • Icon systems and platform conventions
  • Loading states and transitions

Accessibility Question

I’m curious about your accessibility experience. Web has better semantic HTML and accessibility APIs in some ways. But native platforms have deep integration with platform assistive technologies.

How did accessibility compare PWA vs native in your testing? Did you lose anything, gain anything?

The Balance Question

Can a PWA feel native enough to meet user expectations without compromising on the cross-platform benefits?

Or is the answer: Don’t try to feel native, embrace a distinct design language that works everywhere?

Really interested in how your design team approached this. Did you try to match platform conventions or go with a unified design language?

  • Maya
5

David, this is super timely. We’re evaluating PWA for our EdTech product and your case study validates a lot of our thinking.

Our EdTech Context

  • 80 engineers, 25 currently on mobile (iOS and Android teams)
  • Serving K-12 schools across the US
  • Students access from: Chromebooks, tablets, phones, shared lab computers
  • Budget constraints: Many schools can’t afford device deployments

Why PWA Is Compelling for Education

Device Diversity
Schools have a wild mix of devices:

  • Chromebooks (can’t run iOS/Android apps)
  • Old iPads (won’t update to latest iOS)
  • Budget Android tablets
  • Shared computer labs
  • Students’ personal phones

A PWA works on all of them without separate builds or App Store/Play Store restrictions.

IT Administration
Many school districts have locked-down devices where students can’t install apps. But they can access websites. PWA removes that barrier entirely.

Update Distribution
Getting schools to update apps is… difficult. With PWA, updates are instant. Critical bug fixes don’t wait weeks for IT to approve and deploy.

My Concerns

Performance on Older Devices
Many schools have 3-5 year old Chromebooks or tablets. How does PWA performance hold up on low-end hardware compared to native? This is critical for us.

Offline Reliability
Students need to work offline (patchy WiFi, taking devices home). How reliable is offline functionality in real-world conditions with service workers?

The Team Consolidation Question

This is huge for us: We have 25 engineers split between iOS, Android, and web. If we move to PWA:

Before:

  • 10 iOS engineers
  • 10 Android engineers
  • 5 Web engineers
  • Fragmented teams, duplicate work

After PWA:

  • 25 engineers on one platform
  • Shared knowledge
  • Faster feature development

But: What happens to our native expertise? Do we retrain? Reorganize? What was your team structure before/after?

David, can you share:

  1. Your team size before the consolidation?
  2. How many mobile engineers transitioned to web/PWA work?
  3. Any layoffs or restructuring?
  4. How long did the team take to become productive on the new stack?

The ROI Question

Your numbers are compelling:

  • 60% faster velocity
  • 40% lower operational cost
  • 25% lower CAC

For an engineering leader, that’s hard to ignore. But there’s also:

  • Transition cost
  • Team restructuring
  • Risk of losing mobile expertise
  • Potential user satisfaction hit

How long did it take to see positive ROI after accounting for transition costs?

Really valuable case study. Thanks for sharing the real numbers.

  • Keisha