Inside Bluesky’s Engineering Culture
A deep dive into how a fully remote, open source-first, tech company is building a challenger social media platform. What can small teams learn from Bluesky about punching above your weight?
This deepdive was written in May 2024, months before Bluesky started to get millions of new users every week. To read deepdives about interesting tech companies and technologies early, subscribe to The Pragmatic Engineer:
Bluesky is a promising decentralized Twitter-alternative. Founded two years ago, the company received $13M in funding from Twitter in 2021. Today, it employs 12 software engineers, with more than 5 million users a year on from its invite-only beta launch.
Previously, we looked into the social media platform’s architecture and engineering decisions in Building Bluesky: a distributed social network (real-world engineering challenges). In this article, we learn about the team and the engineering culture, covering:
Unusual origins. It’s rare for publicly traded companies to fund startups which may become rivals – but it happened with Bluesky.
Team. A high ratio of former founders amongst the engineering team (70-80!%) , and the near-absence of Big Tech experience.
Tech stack. TypeScript, Go, ScyllaDB, SQLite, React+Expo.
Company culture. Full-remote with a time zone overlap, “extremely online.”
How the team operates. 2-3 person teams with a DRI, work buddies for everyone, and lots of longform writing.
Engineering culture. Integration tests over unit tests, roll-back / roll-forward, & the benefits of not having large-scale organizational expertise.
Open source and community. Treat contributors well, invest in developer platforms and documentation, and celebrate/promote third-party contributions.
By the end of this article, you’ll hopefully understand how a dozen engineers build and operate a product with such outsized impact in its millions of users and fast growth. Small but very efficient engineering teams are increasingly popular – especially with the end of 0% interest rates – as “efficient” software engineering teams become the norm, industry-wide.
1. Unusual origins
Bluesky kicked off in 2019 with a now-iconic TWEET from then-Twitter CEO, Jack Dorsey.
Potential candidates sent DMs (direct messages) to Jack, of whom around a dozen were invited to join a Matrix chatroom, where he provided a prompt for discussing ideas, which read:
The biggest and long term goal is to build a durable and open protocol for public conversation. That it not be owned by any one organization but contributed by as many as possible. And that it is born and evolved on the internet with the same principles.
CEO of Bluesky, Jay Graber, was one of this small group, which also included:
Jeremie Miller: prolific contributor to the Extensible Messaging and Presence Protocol (XMPP) used today in apps like Whatspp, Kik Messenger, and Zoom.
Matthew Hodgson: technical cofounder of Matrix, an open protocol for decentralized, secure communications.
Ian Preston: cofounder of Peergos, a platform trying to build the “next web,” where end users are in control of their data. Also an early Twitter engineer.
The group was made up of heavy hitters in decentralized messaging protocols, and entrepreneurs aiming to advance and evolve the web.
In mid-2020, Jay proposed writing an ecosystem review of existing decentralized social networks and technologies. As this review was developed, the chatroom grew to ~60 people. By the end of 2020, Twitter put out a request for proposals in the group. Several people responded, including Jay Graber.
Twitter ran an interview process in 2021 to select the Bluesky project’s lead, and Jay was announced as the choice that August:
A unique setup
Unusually, Bluesky spun up as an independent organization, not as part of Twitter. Mostly, when a company announces funding for a new initiative, it becomes an internal division of the company. But in this case, the opposite happened: Bluesky was external to and independent of Twitter from day one.
Jay used her own money to hire Daniel Holmgren and start prototyping while the details were being finalized. Together, they fleshed out a protocol Jay had coauthored with technical advisor whyrusleeping back in 2018 – a core design that persists in Bluesky to this day.
The project got the green light on 31 December 2021, when Twitter paid the newly formed entity a substantial sum of $13M to build the AT Protocol, and also the sign off for Bluesky to work fully independently. Actually, there was one condition from Twitter:
“Twitter's funding of Bluesky is not subject to any conditions except one: that Bluesky is to research and develop technologies that enable open and decentralized public conversation.”
It’s common for companies raising funding from investors to pursue a bold vision, but it’s extremely rare for a publicly traded company like Twitter to fund a startup and hand it a pretty much free rein. This was likely due to Jack's personal interest in the project, but also stems from Jay's conviction about what the project needed. In her own words:
"I negotiated six months for independence because being a subsidiary of Twitter wasn't a viable option. The company moved too slowly, and I felt there was too much risk that Bluesky could be killed as a project if leadership changed. That turned out to be true."
Jay told us that she negotiated for six months for independence because she wouldn't accept that being a subsidiary of Twitter would be a viable option. Jay felt that Twitter moved too slowly and felt there was too much risk that Bluesky could be killed as a project if Twitter’s leadership would have changed. And how true this assumption was – given how in November 2022, Elon Musk acquired Twitter and made drastic changes from the start.
Business model
Most VC-funded businesses in the US are limited liability companies (LLCs,) and for-profit. Not Bluesky. It’s a Public Benefit C-Corporation (PBC,) meaning its primary mission is the “public good,” not necessarily profit.
This difference could give Bluesky a slight advantage over regular for-profit companies: they don’t need to focus solely on generating returns for shareholders like publicly traded companies must, or being commercially viable straight away with a product-market fit. Instead, Bluesky could focus on the mission to “develop and drive large-scale adoption of technologies for open and decentralized public conversation.”
But this also comes with risk because it dodges the need to define a business strategy in the short term, even though it’s known that strategy is a big ingredient in long-term success.
We asked Bluesky about this risk. After all, why would users trust a service that could run out of cash, due to being focused on its mission, instead of making money? Here’s what the team says:
Different incentives from traditional social media companies. Due to the openness of Bluesky’s architecture, users are not locked in. Whether it's what client app they use or what algorithm they use for their primary feed, users can choose Bluesky’s defaults, or switch to another provider. Since the cost to switch is so low, Bluesky is incentivized to monetize in ways that will keep users happy. On the other hand, Twitter banned third-party clients in 2023, as they didn’t serve ads.
Exploring paid services as value-adds. In order to not depend on external funding, Bluesky has a business vision to sell paid services. The first is partnering with Namecheap to sell custom domains, which are a big part of Bluesky. Now, when someone registers a domain through Namecheap, Bluesky gets a small commission.
The existing monetization strategies that traditional social media companies use, like selling user data for ads, would not be as effective for Bluesky. So, they’ll need to find new ways to monetize. An interesting observation by Bluesky’s developer relationships engineer, Emily Liu:
“We’re using this period of time to explore what services will be valuable for users, like custom domains that users can purchase and manage through Bluesky. We’re turning a social app inside out — unlike the centralized social media giants, we don’t have a monopoly on user data, and so we aren’t following a super traditional monetization path.”
There are examples of companies that became PBCs and enjoyed success, or even went public. Insurance technology startup Lemonada went public in 2020 with this setup. Education startup Coursera is also a PBC, as is the eyewear company, Warby Parker.
2. Team
Today, Bluesky has around 40 full-time staff:
17 in “core” team, of which 12 are developers
Circa 20 people in support and moderation
Fun fact: none of the early hires ever worked at Twitter! (The first person hired with past experience at Twitter was brought onboard in 2024.) I find this interesting, as since Bluesky was founded, Twitter has laid off 75% of its workforce – some of whom may have considered joining the new social media startup.
Team structure
In the core engineering team, everyone is on Bluesky, and we’re linking their profiles.
Protocol/backend and infra: 5 people, working mostly in the Atproto repository and Indigo repo. Daniel Holmgren, Devin Ivy, Bryan Newbold, Matthieu, and Jaz.
Frontend & apps: 5 people. They do most of their coding in the Apps repository. Paul Frazee, Eric Bailey, Dan Abramov, Hailey and Samuel.
Moderation / labeling: 1 person. This is the Ozone service built by Foysal Ahamed.
Other: 5 people. Jay Graber (CEO), Rose Wang (growth), Aaron Rodericks (Head of T&S), whyrusleeping (technical advisor) and Emily Liu (developer relations/growth)
You don’t need to work at Bluesky to map the engineering structure. In most company deep dives, we ask current or past employees to get the team structure. But for Bluesky, you can simply inspect the projects within the Bluesky repository, and map Github contributors to their Bluesky handles! All code that Bluesky engineers write is in public, and I’m somewhat surprised just how transparent this all is, in a good way.
Unusually high ratio of former founders
Close to 4/5 of the “core” team have been founders before, which is extremely unusual at a startup. Of course, startups attract people who prefer working in small teams, some of whom have also been founders. But what attracted so many to Bluesky?
From talking with the team, it comes down to:
Belief in Bluesky’s greater mission
Building decentralized web experiences
Bluesky is building a social network, to scale. If anyone knows how to rapidly scale up, it’s people at Big Tech companies with personal experience of it; think engineers at Google in the early 2000s, those at Facebook in the mid-2000s and early 2010s, those at Netflix in the 2010s, etc. But Bluesky had no such people among its first few engineering hires.
Founding engineer Paul Frazee shares:
“A lot of the core team's experience really just came from previous decentralized web or decentralized social projects; way more than from high scale social networks.
“We had a ton of experience with peer-to-peer networks, and had paid a fair amount of attention to the blockchain world. For the initial team, this was the second, third, or even fourth time building a decentralized network.”
3. Tech stack
Typescript (almost) all the way
The backend is mostly in Typescript, as is the frontend and mobile apps. This allows software engineers to work across the stack without switching languages. This choice is similar to Linear’s to use Typescript between the back and front ends.
Why pick this language? Daniel Holmgren gives several reasons:
De facto language of the web. “Javascript and therefore Typescript is probably as close as we have to a ‘lingua franca’ for the web. We felt it was a natural choice to communicate the core ideas in the reference implementation of the protocol.”
Shared front and back end language. “Having a shared implementation across the client and backend makes for a nice development experience, especially knowing that both sides have a shared understanding of the schema system.”
Fits the AT protocol’s dynamic data approach. “Being a dynamic language, Typescript has been great for working with the dynamic data you find in the ATproto ecosystem.”
A great fit for code generation. “Typescript has a really great ecosystem for code generation. I think it's that the actual official TypeScript implementation just ships the tooling for parsing into an AST and then manipulating it and outputting code. Not many people were needing that, but I was really happy it was there.”
Great for prototyping with a small team. “Typescript is a great language for quick building. The runtime is quite powerful and lets you not worry (much) about things like memory management and concurrency. The type system is very ergonomic and provides the structure you need, while seldom getting in the way. With such a small early team, it made sense to choose a language that enabled us to prototype quickly.”
Node.js
The Typescript code on the backend uses the Node.js runtime. One worry the team had was how it would scale, as Node.js app runs in a single thread, without creating a new thread for every request. This means a server running Node.js can handle fewer parallel requests than frameworks that support multi-threading more efficiently.
However, the team found it's very easy to scale the service horizontally (adding more machines,) but only by building the application to be stateless. They did this, and Daniel recalls they proved a point:
“At one point, we had around 192 node processes running behind HAProxy. All these processes were super ‘bored,’ at around 1% CPU utilization. But the point is that it’s very easy to scale a stateless Node service out horizontally – so that's what we did!”
Go for performance
The backend started out as Typescript, but over time, Go was introduced. But why bring in another language when Typescript works well enough? Performance, says Daniel:
“Some of more infra-y services such as the Relay and our internal ‘Dataplane’ are very performance-based. They often involve a lot of crypto operations and low-level bit twiddling. These are things that Go excels at. In particular, Go has a shard-aware driver for Scylla (a database we use) which made it a natural choice for interfacing with it.”
The team has rewritten services from Typescript to Go when performance improvements warrant it. Services in Go, today:
Search services like Palomar.
The “firehose” called Relay. This service does a lot of low-level fiddling and crypto operations.
Dataplane. This service is called the “BigSky service,” and is one of few closed-sourced services. This service manages data, talking to ScyllaDB, as well as some other data stores like Redis, and their own handwritten cache stores.
Data layer: Postgres, ScyllaDB, SQLite
Bluesky started out with PostgreSQL as the data store, but as the load grew the team expected the time would come to move off this flexible but potentially less scalable solution, to a less flexible, more scalable one.
Migration happened in mid-2023:
ScyllaDB powers AppViews.
SQLite is the database of choice for the personal data servers (PDSses.)
We cover more on the data layer migration in Part 1: Scaling the database layer.
Backend-to-frontend communication
The Lexicon schema is used to describe HTTP endpoints and all of the record types in the network. This approach ensures strongly-typed contracts and agreements between backend and client.
Such strong contracts are especially important for a decentralized network. Bluesky is also an open microservices network, so being stricter at the protocol level makes sense. Paul Frazee puts it like this:
“You can think of the entire network as an open microservices network. It's not terribly uncommon when you're doing microservices to try to systemize it through a schema language, to make sure that the contracts are being obeyed throughout all these different things, as you don't have the benefit of a monolith.”
Build tooling
The team uses GitHub Actions for the CI/CD stack. The project is running in the open, so you can inspect these runs yourself:
The builds themselves use common tools and techniques for catching quality issues early:
Linting: run static code checks to catch coding issues, and ensure the coding style is consistent across the codebase. Here’s an example of the types of issues Bluesky’s linter has captured:
Automated tests: run unit, integration and snapshot tests.
Example of a snapshot test:
Mobile and web stack
One fascinating thing about Bluesky is that the website, iOS app, and Android mobile app, were all built by a single developer. From summer 2022 until early 2023, it was engineer Paul Frazee who worked on this, alone. Early in 2023, the app had some external contributors, and the second full time hire joined in April. The tech stack that enabled all of this was React Native and Expo:
On choosing React Native, Paul Frazee explains:
“We knew we wanted to hit all of the major platforms right from the start, and given our Typescript focus, there was only one viable way to do that: React Native.
If you have two separate application codebases, then you have two separate products. You’re implementing everything twice, and you’re debugging everything twice, and the outcomes are all going to slightly vary.”
But React Native is not a “magic bullet” solution, says Paul:
“It’s not easy. Some days it’s maddening. A lot of web developers know how frustrating it is to target multiple browsers; now imagine targeting native iOS and Android, as well. That said, this is a choice between ‘kind of frustrating sometimes’ and ‘impossible.’”
Expo is a platform to develop, review and deploy universal native apps that run on the web, iOS and Android. Bluesky introduced it in March 2023, and while the team was careful in limiting the introduction of new dependencies, the purpose was to manage builds and access Expo’s module ecosystem.
React Native for web was a choice that surprised even the development team. Initially, Paul intended to use React Native only for mobile apps, but then they found React Native is pretty manageable for the web. Paul explains:
“The amount of stuff we're able to do with code sharing is just stellar. We've got shared code running everywhere, from our backend all the way into each of these different platforms, and that's part of why we've been able to do this with a small team.”
“One-person” mobile app
As mentioned above, The Bluesky mobile app and website were built by a single developer in around a year, Paul Frazee. Today, six engineers work on the app and website, and roughly the same number on the protocol and backend side.
Still, it’s remarkably efficient to build a launch-ready app with a single, experienced engineer. So how did Paul pull it off?
He started off by building the protocol, not the app. For the first 6 months, Paul worked with Daniel and Jay, in consultation with Twitter, to figure out how the protocol would work. Bluesky’s idea was that the protocol would be the more important part, and there was an expectation they’d eventually build an app. But this realization didn’t occur until mid-2022. From Paul:
“We always knew we would build an app, because we believe that protocol development should be done in conjunction with app development, but we initially thought it would be more of a prototype. It wasn’t until our relationship with Twitter changed that we realized we’d need to operationalize the protocol and make a full application. So, that was a bit of a shift.”
The relationship between the backend team of Daniel and Devin, and Paul on the frontend/app team was like a traditional frontend/backend one. They spec’d out features together and discussed what each needed to do. They then worked on their own areas and coordinated on final outcomes.
Building the app helped evolve the protocol, and made the work more fun, Daniel recalls:
“The most fun thing has probably been seeing our ideas come to life by building the social app on the protocol. It’s one thing to build/design a protocol in the abstract, but seeing it actually working in practice is another.”
4. Company culture
 | A guest post by
|