Bridging feels seamless. Behind the scenes, it's a technical marvel

Link: Bridging on a budget, by Ryan Barrett at A New Social

I’ve been in awe of Ryan Barrett since I first met him over a decade ago. He cofounded Google App Engine and led engineering at Color Health. His Bridgy tool, which allows people on different protocols and networks to follow and converse with each other, is now the basis of A New Social, the open social web non-profit that he runs with Anuj Ahooja. (Disclosure: I’m on the board.)

This post about how he reduced Bridgy costs is brilliantly detailed. It’s a good look into what’s involved when you need to refactor and reduce cost at scale — and what’s remarkable is how effective this work actually was.

“The end result of all of this is that we grew from 2k users to almost 150k, added a ton of heavy new functionality, and still managed to optimize and cut down costs from $.15 per active user per month to just $.03 or so.”

But it didn’t come easily. When you’re connected to the kinds of firehoses that Bridgy needs to be, and serving the kind of traffic it’s starting to handle, every optimization really counts. Because it’s open-source, you can dig down into individual optimizations and follow along each exploration. It’s painstaking work and a demonstration of their commitment to financial responsibility. Try vibe coding that.

Bridgy (and its parent A New Social) exists to help make the individual protocols less important: everyone should be able to collaborate with everyone else regardless of which platform they’re using. It’s the kind of thing that feels easy in the moment — but as this post proves, it’s far from simple under the hood.