Googlers promoted for launches, not landings: Why web suffers

Google’s most popular apps basically scream at you these days: “It works better in the app.”

I’ve watched this happen for years—they slow-walk the web to the point where loading the mobile site feels like being punished. Search results? Tap a link and you’re often redirected to a page that looks like it was designed in 2007, stuffed with cookie banners and newsletter pop-ups. But the Android app? Clean, fast, and oddly personal—even though it’s still just serving you the same content. It’s not that the app is better. It’s that the web version is held hostage.

Which makes you wonder: why does Google keep doing this?

Technical Overview

That mobile apps still dominate social networking isn't just an inconvenience—it's a fundamental mismatch between web technologies and how we actually use the internet now. The web isn't just a second-class citizen here; on mobile devices, it's often completely absent. When Twitter, Facebook, or TikTok want you to check their sites, they'll either show you a blank screen with a tiny "download app" button or redirect you to the App Store. This isn't accidental design; it's a deliberate choice by platforms that prioritize control over reach.

The technical reason isn't complicated. Mobile browsers have strict limits on how much they can do compared to native apps. Background sync, push notifications, and smooth animations all work better when they're not fighting against browser sandboxing and JavaScript throttling. Even basic things like login flows tend to break on mobile web versions because the OAuth dance between browser tabs and app switches doesn't play nice with platform restrictions. The result? Every social network has its own app with its own sign-in flow, its own push notification system, and its own way of locking you into their ecosystem.

This creates a real problem when you're trying to build something that needs to work across platforms without forcing users to download yet another app. The web offers portability—no installs, no updates, no platform-specific weirdness—but it lacks the features that make social apps sticky. Push notifications? Only with service workers, and even then they're unreliable. Background sync? There's a 30-second service worker timeout on mobile Chrome. Deep linking? It's a minefield of app store redirects and universal link failures.

Here's what actually works today:

<!-- Basic service worker setup for push notifications -->
<script>
  if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('/sw.js')
      .then(reg => console.log('SW registered'))
      .catch(err => console.log('SW registration failed'));
  }
</script>

The sw.js file would need a push subscription endpoint and would handle incoming messages, but this is where it falls apart. Most browsers throttle service workers when the app isn't in focus, so your "instant" notifications aren't instant at all. On iOS, service workers can't run at all in the background—they get terminated immediately. Android is better, but even there, you're fighting against Chrome's aggressive throttling after the app hasn't been used for a few minutes.

The frameworks trying to bridge this gap—Capacitor, Cordova, React Native for Web—are all workarounds, not solutions. They either bundle a browser engine into your app (defeating the point of cross-platform development) or force you to accept that your "web app" is just a thin wrapper around native views. Neither approach solves the fundamental problem: browsers can't compete with native APIs when it comes to the features that make apps valuable.

If you're building something that needs to exist on mobile, you're stuck choosing between fragmentation and lock-in. The web gives you reach but takes away the features users expect. Native gives you control but locks you into platform-specific development. There's no clean technical path forward—just a series of compromises that get uglier the closer you look.

Industry Impact

Launch velocity still trumps sustainable systems in most orgs I’ve watched. That doesn’t mean every manager chases a quick hit—plenty are quietly maintaining the sprawl they’re asked to ship—but the promotion math remains crude: a splashy launch moves you up the ladder, while the next two years of bug fixes and API debt sit in the quarterly OKRs as “non-value-add.” The mismatch isn’t ideological; it’s reward structure. Until the metrics tracking promotion-worthiness value steady state at least as high as new thing, we’ll continue to see the same cycle: surface-level polish over deep interop, and ecosystems that optimize for user lock-in because the org chart rewards it.

What’s more interesting is where that leaves open standards. Google’s behavior with web APIs—capturing traffic through proprietary stacks instead of baking into the platform—isn’t some grand conspiracy, it’s a rational outcome of the same incentive. Open specs slow down when the upside lands on one side of the table. Yet the pushback is starting to look different: regulators are no longer satisfied with “we built a better mousetrap,” they’re asking why the mousetrap is the only option. That changes the calculus for product teams that previously relied on API exclusivity as a moat. If the cost of maintaining proprietary extensions starts to exceed the revenue they lock in, the math flips.

So the real question isn’t whether companies will pivot to open standards; it’s whether they’ll pivot fast enough to matter before the next shiny thing distracts them.

Conclusion

Google’s promotion incentives aren’t just baked into the company’s culture—they’re the operating system. If engineers are being rewarded for the idea of shipping something rather than the grind of making it actually work, you don’t need a crystal ball to see where this ends. The bug list is two years long, the documentation is a cautionary tale, and the users are still stuck with whatever shipped in beta. That’s not innovation. That’s just cargo cult engineering with bonus pay.

And the worst part? It’s not even subtle. The same people who’ll pat themselves on the back for a launch are the ones complaining in internal forums about how the feature “just doesn’t work in production.” They know. Everyone knows. The system rewards the performance of launching, not the performance of the launch itself. So why would anyone bother fixing what’s already “finished”? The math is simple: finishers get promoted slower than launchers, and the next shiny thing is always right around the corner.

Still don’t know what to make of the fact that the company’s best engineers are incentivized to abandon their own work before it’s done.