Build on the Protocol, Not the Platform: How Open Standards Are Winning the Network Effect Game

Here's a question worth sitting with: why does email still work?

Not just work — thrive. Email is decades old, technically unsexy, and has been declared dead approximately once a year for the last fifteen years. And yet it remains the connective tissue of digital communication for billions of people. You can send a message from Gmail to a self-hosted Postfix server to a ProtonMail inbox without a single API key, partnership agreement, or platform permission.

That's not an accident. That's what a protocol does.

While Silicon Valley spent the last decade building network effects through platform lock-in — getting users hooked, raising switching costs, and then extracting value — a quieter movement has been proving that the same dynamics can emerge from open standards. And the resulting networks are, in a lot of ways, more powerful.

What Network Effects Actually Require

The standard playbook for building network effects goes something like this: get users onto your platform, make the experience better as more people join, and then make it painful to leave. Twitter, Facebook, Uber, Airbnb — they all ran some version of this strategy. The value is real. The lock-in is intentional.

But network effects don't actually require a gatekeeper. They require interoperability — the ability for participants to interact with each other in ways that become more valuable as the network grows. A protocol can deliver that just as well as a platform, with none of the centralized control.

The difference is architectural. A platform concentrates the network's value in a single node. A protocol distributes it across every participant. When the platform goes down, gets acquired, or decides to change its terms of service, the network suffers. When a protocol is healthy, no single failure point can take it out.

The ActivityPub Story

The clearest recent example is ActivityPub, the protocol underlying the Fediverse. Mastodon, Pixelfed, PeerTube, Lemmy — these are different applications with different use cases, but they all speak the same protocol. A Mastodon user can follow a PeerTube channel. A Pixelfed post can surface in a Mastodon feed. The network effect isn't owned by any single app; it's shared across the whole ecosystem.

When Elon Musk's acquisition of Twitter sent millions of users looking for alternatives, Mastodon grew faster than any single team could have supported. But because the underlying protocol was open, dozens of compatible servers and apps absorbed that growth in parallel. No single company had to scale to meet the demand. The protocol scaled instead.

That's a fundamentally different kind of resilience than anything a platform-first approach can offer.

The AT Protocol and Bluesky's Bet

Bluesky's AT Protocol takes this further by treating the social graph itself as portable infrastructure. The idea is that your identity, your follows, your content — none of it is tied to a specific server or application. You can move between clients and hosts without losing your network.

This is a direct architectural response to the Twitter problem. When a platform owns your social graph, they own your switching costs. When the protocol owns it, nobody does — which means competition has to happen on actual product quality, not on who got there first and built the highest walls.

The technical bets here are interesting. AT Protocol uses DIDs (Decentralized Identifiers) for identity and a distributed data repository model called the Personal Data Server. It's complex infrastructure, but the user-facing promise is simple: your account is yours, regardless of what happens to any particular app or host.

Why Developers Should Bet on Protocols

For teams building products today, the protocol-vs-platform question has real strategic weight.

Building on top of an open protocol means accepting that you can't build a moat through exclusivity. Your competitors can interoperate with your users. That sounds scary until you realize it also means your users can come from anywhere in the ecosystem — not just from people you've directly acquired.

The Mastodon ecosystem is a good model here. Dozens of clients compete on UX, features, and community norms, but they all share the same underlying social graph. Nobody owns the network, which means everybody can participate in it. Competition is real, but it's on merit.

For infrastructure and developer tooling specifically, protocol-first design often wins on adoption too. The reason tools like Kubernetes, gRPC, and GraphQL spread so quickly is that they defined interaction patterns that could be implemented independently. Nobody had to wait for a single vendor to ship a feature. The community built implementations in parallel.

Architecting for Zero Switching Costs

If you're building something new and want to apply this thinking, the core principle is: design your data formats and interaction patterns to be portable from day one.

That means using open standards wherever they exist. It means publishing your API schemas. It means thinking about how a competitor could build an interoperable client against your backend — and making that easier, not harder. It means your users' data should be exportable in formats that are useful outside your system.

This feels counterintuitive if you've been trained to think about moats. But the long game here is that a network built on open protocols attracts more participants, generates more trust, and survives longer than one built on lock-in. The email protocol is fifty years old. Twitter is already struggling to stay relevant at twenty.

Build the protocol. Let the platforms compete on top of it. That's how you build something that actually lasts.