--- meta: title: "Build vs. buy realtime collaboration with AI" parentTitle: "Compare" description: "Compare building collaboration with an AI coding assistant and using Liveblocks. See who owns document sync, persistence, permissions, recovery, and maintenance." --- Liveblocks is a realtime collaboration platform that allows you to build multiplayer applications where users and agents can work together. It provides a sync engine that powers shared documents, text editing, presence, and more. Building with an AI coding assistant means asking the assistant to generate a bespoke collaboration back end: the WebSocket server, the merge logic, the persistence layer, and the permission checks, which your team then runs and maintains. ## Which should you choose? [#which-should-you-choose] A custom build and Liveblocks solve different problems. A custom build is a sync engine your team owns and operates, whereas Liveblocks is a sync engine you build your product on top of. Choose Liveblocks when the feature you want to ship is shared editing, such as a planning board, a whiteboard, or a document with comments, and your team wants to spend its time on the product rather than on reconnection and merge logic. Build your own when you need protocol behavior or an infrastructure arrangement that no service provides, such as a proprietary wire format or a deployment that cannot leave your network, and you can staff the ongoing operation. Many teams [use an AI coding assistant with Liveblocks](#can-i-use-an-ai-coding-assistant-with-liveblocks). ## Compare the responsibilities [#compare-the-responsibilities] | Area | Liveblocks | Building your own with AI | | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Persistence | Shared documents in Storage. A CRDT-based document store. Concurrent edits merge automatically, and data is kept until you delete it. Learn more. | A database you choose, plus the snapshot and history logic you write. | | Realtime updates | Document changes, presence, and broadcast events. Presence is short-lived per-user state such as cursor position or selection. Presence, client API. | A WebSocket server the assistant generates, or a library such as Socket.IO. Socket.IO handles connections and event delivery. It does not merge or store data. Learn more. | | Conflict resolution | CRDT-based. Concurrent edits to objects, lists, maps, and text merge automatically. Writes to the same single value are last-write-wins. Learn more. | Whatever the generated code does, typically last write wins, unless you add a CRDT library such as Yjs. Yjs is an open-source CRDT library. You still need to write the server, persistence, and permissions around it. Learn more. | | Reconnection | Built in. Clients reconnect and catch up automatically. | Reconnect, replay, and offline-edit handling you design and test. | | Text editing | Built in, with Tiptap, BlockNote, Lexical, and more. Official packages for popular editors, plus Yjs guides for others. Learn more. | Not built in. Requires a CRDT library and an editor binding you connect and test. | | Ready-made UI | Cursors, avatar stacks, comments, and notifications. React components you can drop in, plus hooks for building your own. Cursors, AvatarStack, Comments, Notifications. | None. Every component is generated, then maintained by your team. | | Authentication | Your server issues access tokens using your existing auth. Works with any auth provider. Tokens grant access to specific rooms. Learn more. | Your existing auth, plus per-document permission checks you write and enforce on every message. | | Operations | Managed service. Self-hosting available on the Enterprise plan. Liveblocks runs the servers, scaling, and upgrades. Self-hosting is a paid add-on. Learn more. | You run the servers, scaling, monitoring, and upgrades. | | The main question | Which parts of your app should people edit together? | Does your team want to own a sync engine? | ## Can I use an AI coding assistant with Liveblocks? [#can-i-use-an-ai-coding-assistant-with-liveblocks] Yes. A coding assistant can build the interface, connect the supported editor integrations, and implement business rules around Liveblocks, starting from the [setup guide](/docs/get-started). The choice is not whether to use AI. It is whether your team also owns the synchronization system underneath the code the assistant writes. The [whiteboard example](/examples/tldraw-whiteboard/nextjs-tldraw-whiteboard-storage) is a good starting point for a shared canvas. Point the assistant at it, adapt the interface and document model to your product, then test permissions and concurrent editing. ## What work remains after AI builds a prototype? [#what-work-remains-after-ai-builds-a-prototype] The cases a demo doesn't show. Suppose you ask a coding assistant to build a planning board with live cursors and editable cards. Two browser windows showing the same update proves one thing works. Before shipping, decide what should happen when: - Two people edit different fields on the same card, then both edit the same field. - One person changes text while another inserts text at the same position. - Someone disconnects, keeps editing, and returns after another person has changed the document. - A user loses permission while their session is still open. Write down the expected result for each case, then test either implementation against it. Liveblocks still needs deliberate data modeling. How it [resolves conflicts](/docs/guides/how-conflict-resolution-works-in-liveblocks-sync) depends on the data type: edits to separate fields all survive, but concurrent writes to the same single value are last-write-wins. A managed service does not decide what your product should do when two people assign different owners to a task. ## Custom sync engine vs. managed service [#custom-sync-engine-vs-managed-service] A custom system can make sense when you need specific protocol behavior, an infrastructure arrangement, or a level of control that no service you evaluated provides. Plan for the engineering ownership that comes with those requirements: the server, persistence, recovery, and permissions are all yours to run and update. A custom build doesn't have to start from zero. [Yjs](https://docs.yjs.dev/) provides a CRDT for the shared data, and [Socket.IO](https://socket.io/docs/v4/) provides event delivery. Asking AI to assemble those tools is different from asking it to invent every layer, but your team still has to validate how the pieces work together and keep them working as each one changes. Liveblocks is a fit when [Sync](/docs/products/sync) and the collaboration products cover the feature you want to ship. Your team can use AI to build the application around that foundation: the interface, document structure, permissions, and workflows that make the product useful. ## Work through one concurrent update [#work-through-one-concurrent-update] Start with a card whose title is "Launch" and owner is "Maya." Alice changes the title to "Launch plan" while Ben changes the owner to "Lee." Because those are separate fields on a `LiveObject`, both changes are kept. If both change the owner, only one value remains, following the documented [conflict resolution](/docs/guides/how-conflict-resolution-works-in-liveblocks-sync) rule. A custom build needs an explicit answer for both cases. A full-object overwrite erases the unrelated title change. Field-level updates avoid that problem, but concurrent text still needs a CRDT. Ask the coding assistant to write down those expected outcomes before it writes the implementation. ## Pricing and deployment [#pricing-and-deployment] A custom build has no subscription, but it is not free. Estimate the same feature both ways: implementation, production testing, infrastructure, incident handling, dependency updates, and every later change to the document model. Include the cost of the AI tools themselves. Generating the first version says little about the lifetime cost, and neither approach is automatically cheaper. Liveblocks is a plan plus usage. Your [plan's credits](/docs/pricing/plans) apply once across all Liveblocks usage. A custom build is self-hosted by definition. Liveblocks offers [self-hosting](/docs/platform/data-storage#Self-hosting) as a paid add-on on the Enterprise plan. Either way, your own servers, database, backups, and operations are part of the budget. ## Get started [#get-started] Start from the [whiteboard example](/examples/tldraw-whiteboard/nextjs-tldraw-whiteboard-storage) and the [setup guide](/docs/get-started). Define the product behavior you want the assistant to build around that foundation. [Start building with Liveblocks for free](https://liveblocks.io/dashboard). --- For an overview of all available documentation, see [/llms.txt](/llms.txt).