The Quiet Takeover Happening in Collaborative Software Infrastructure
When developers talk about building real-time collaborative features – think cursors, live presence, comments, document co-editing – the conversation used to start and end with infrastructure players like Ably. Ably built its reputation on reliable pub/sub messaging and WebSocket infrastructure, and for a long time that was enough. But the requirements of modern collaborative apps have shifted in ways that raw messaging infrastructure was never designed to handle, and Liveblocks has spent the last two years positioning its multiplayer SDK directly in that gap.
Liveblocks does not compete with Ably on WebSocket primitives. It competes on everything above them – the layer where developers actually spend most of their time. Pre-built conflict resolution, collaborative text editing with CRDT support, live cursors, comment threads, notification systems, and presence indicators all arrive as ready-to-ship components rather than engineering exercises. That distinction is starting to matter to a very specific, fast-growing segment: product teams at B2B SaaS companies who need Figma-style collaboration without a multi-year engineering investment.
Where Ably’s Model Shows Its Age
Ably is a serious product. Its global edge network, channel architecture, and uptime guarantees made it a natural choice for developers who needed low-latency pub/sub at scale. The problem is that “give developers a reliable pipe” is a different product vision than “give product teams working multiplayer features.” Ably’s model assumes you have engineers who want to build; Liveblocks’ model assumes you have teams who want to ship. Those are different buyers, and increasingly, the buyer making purchasing decisions inside SaaS startups is the latter.
The practical gap shows up in onboarding time. Standing up live cursors and conflict-free document syncing on top of Ably requires abstracting pub/sub into collaborative state management, building your own presence logic, and handling edge cases that only appear under real multi-user load. Liveblocks ships all of that as a starting point. A developer can have collaborative text editing working in a single afternoon without writing the underlying sync logic from scratch.
This is not a subtle difference in developer experience. It represents a fundamental rethinking of where the SDK’s responsibility ends. Ably says its responsibility ends at message delivery. Liveblocks says its responsibility ends when your users can see each other’s cursors moving in real time. For startups with small engineering teams and aggressive product roadmaps, the second answer is worth paying for even if the underlying infrastructure is technically less flexible.
The closest comparison in adjacent markets is what happened when higher-level developer tooling started eating the market for raw cloud primitives. Ably’s infrastructure layer is not going away, but the developers who previously would have built on top of it directly are now reaching for abstraction layers that do more of the work. Liveblocks is betting – correctly, it appears – that the multiplayer SDK layer is where product velocity is actually won or lost.
The Figma Effect and Who It Created
Figma normalized real-time collaboration inside design tools, and then Notion, Linear, and a generation of B2B SaaS products normalized it everywhere else. The downstream effect is a new category of buyer: a product manager or engineering lead at a mid-size SaaS company who has received a product spec that includes “real-time collaboration” as a feature requirement, has six weeks to ship it, and needs a path that does not involve hiring two additional backend engineers.
Liveblocks is built almost entirely for that person. Its component library, React hooks, and pre-built UI primitives are designed to drop into an existing product without a team needing to understand CRDTs or WebSocket connection management. That makes Liveblocks less of an infrastructure decision and more of a product decision – which means it often gets evaluated by people who were never going to evaluate Ably in the first place. Liveblocks is not just winning Ably’s customers; in many cases, it is winning deals that Ably was never in the room for.
Pricing, Positioning, and the Startup Flywheel
Liveblocks uses a usage-based model with a generous free tier, which mirrors the go-to-market approach that has worked well across the developer tools space – get engineers building on the platform before procurement is involved, then convert at scale. This pricing posture makes it easy for a solo developer to prototype a collaborative feature and bring a working demo to their team before any budget conversation happens. By the time finance is in the room, the switching cost has already been established.
Ably also offers free tiers, but its pricing is structured around connections and messages – units that require developers to estimate their own usage patterns, which adds friction for teams that have not yet launched a multiplayer feature and cannot predict load. Liveblocks pricing is structured around rooms and monthly active users, which maps more intuitively to how product teams think about their own growth. Paying for users rather than infrastructure events is a simpler mental model, and simpler mental models close faster in bottom-up sales motions.
The startup-to-growth-stage pipeline also benefits Liveblocks disproportionately. When a company that started using Liveblocks at five engineers scales to fifty, the migration cost of switching to a different collaboration infrastructure is significant. Customer retention in developer tooling is rarely about lock-in tactics – it is about how deeply integrated the SDK becomes into the product’s core architecture. Liveblocks, by providing the data layer, the UI components, and the sync primitives, goes deeper than a messaging bus. That depth is the moat.
The Open Question Around Enterprise Scale
Where Liveblocks faces its toughest test is at genuine enterprise scale – not in terms of users, but in terms of customization requirements. Large enterprise clients often have compliance constraints, specific data residency requirements, or architectural preferences that make abstracted SDKs complicated. Ably’s flexibility at the infrastructure layer becomes genuinely valuable when a customer’s legal team needs to approve exactly where data is stored and how it moves. Liveblocks’ managed approach, which is its primary selling point with smaller teams, can become a friction point with procurement at larger organizations.
Liveblocks has been expanding its enterprise offerings, including self-hosted options and more granular compliance controls. Whether those additions arrive fast enough to compete for mid-market enterprise contracts – where Ably has established relationships – is still an open question. The parallel is worth watching: other SDK-first developer tools companies that prioritized startup adoption and found themselves rebuilding enterprise features under pressure have often found that the upmarket move is harder and slower than the initial land-and-expand thesis suggested.
For now, Liveblocks is accumulating density in exactly the market segment that produces tomorrow’s enterprise clients – well-funded Series A and B SaaS companies with product-led growth models and small but highly effective engineering teams. Those companies tend to standardize early on their core infrastructure, carry their choices upmarket as they scale, and are deeply resistant to ripping out something that already works. Ably’s best counter-argument is the one it has always had: maximum control, minimum abstraction. Whether that argument lands with the next generation of startup buyers is the actual competition happening right now.
