CRDT or Operational Transform — how do we choose?

OT is mature for sequential text editing (used by Google Docs). CRDTs are better for structured data, spatial data, and systems where the server isn't always the authority. The choice depends on your data model — we'll map the trade-offs against your specific schema in week one.

What about Liveblocks or Yjs — why build custom?

Liveblocks, Yjs, and Loro solve 80% of the problem quickly — and we'll tell you if they fit your use case, because they're faster to ship. Custom sync is right when your data model has semantics the library can't express (e.g., a canvas with non-commutative operations), or when the managed layer's pricing doesn't work at your scale.

How do you handle users going offline mid-edit?

Offline edits accumulate in a local CRDT delta log, persisted to IndexedDB. On reconnect, the delta is sent and merged server-side. The merge is deterministic — there's no 'which version do you want?' dialog. The only edge case is intentional hard deletes, which we design as tombstones rather than remove operations.

Real-Time & Collaborative Apps

Real-Time Collaboration Engineering — Live Sync Without the Conflict Tax

Users expect to see each other's edits instantly — no refresh, no conflicts, no lost work. That's not a feature you add to a REST API. It's a different data architecture, a different consistency model, and a different set of failure modes that most sync libraries paper over.

How a CRDT sync cycle works

1
Local edit
User A types — applied to local state optimistically
2
Operation log
Change recorded as a CRDT delta, not a full snapshot
3
Broadcast
Delta sent to all connected peers via WebSocket
4
Merge
Each peer merges deterministically — no conflict dialog
5
Convergence
All clients reach identical state, eventually consistent

Offline edits are queued locally and merged on reconnect using the same deterministic rules.

What you get

CRDT or Operational Transform sync engine designed for your specific data model — text, rich text, canvas, structured data, or custom domain objects

Presence layer: live cursors, user avatars, typing indicators, online/offline awareness, and focus state — propagated in under 50ms

Conflict resolution with defined merge semantics — concurrent edits are merged deterministically, never silently discarded

Offline support with an optimistic local state model and a conflict-resolution strategy for merging offline changes on reconnect

Scalable sync infrastructure (WebSocket, WebRTC data channels, or Liveblocks / PartyKit / Loro if a managed layer fits) sized for your concurrency requirements

Observability for sync state: conflict rate, merge latency, stale client rate — the metrics that tell you if real-time is actually working at scale

When it fits

Multiple users work on the same document, canvas, or data structure simultaneously
Users expect changes to appear without a page refresh — the 'last save wins' model is a user experience problem, not a known tradeoff
You need offline support — users work on flights and in basements, and their work shouldn't disappear
The current solution is polling every N seconds and calling it 'real time'

When it doesn't

Collaboration is sequential, not concurrent — most workflows where only one user edits at a time don't need CRDTs, they need optimistic UI
The data model is append-only (activity feeds, logs, chat) — simpler event-sourcing patterns are usually sufficient
Your team has never shipped a real-time product — consider a managed layer (Liveblocks, Ably) first and bring us in when you've hit its limits

Process

Week 1: data model analysis and conflict scenario catalogue — we enumerate every concurrent edit combination before writing code. Weeks 2–5: sync engine implementation with a test harness that replays recorded conflict scenarios. Weeks 6–9: presence layer, offline support, and scale testing. Week 10: observability dashboards and runbooks.

Full delivery process

Pricing

Fixed-price by data model complexity. Simple text/rich-text: $80–160k. Structured data with custom merge rules: $150–350k. Canvas/spatial (Figma-style): $200–500k. Managed-layer integration (Liveblocks, Loro) is faster and cheaper — we'll recommend it honestly if it fits.

See engagement models

Industries we serve with this

SaaS Startups

EdTech & Corporate Learning

FAQ

CRDT or Operational Transform — how do we choose?: OT is mature for sequential text editing (used by Google Docs). CRDTs are better for structured data, spatial data, and systems where the server isn't always the authority. The choice depends on your data model — we'll map the trade-offs against your specific schema in week one.
What about Liveblocks or Yjs — why build custom?: Liveblocks, Yjs, and Loro solve 80% of the problem quickly — and we'll tell you if they fit your use case, because they're faster to ship. Custom sync is right when your data model has semantics the library can't express (e.g., a canvas with non-commutative operations), or when the managed layer's pricing doesn't work at your scale.
How do you handle users going offline mid-edit?: Offline edits accumulate in a local CRDT delta log, persisted to IndexedDB. On reconnect, the delta is sent and merged server-side. The merge is deterministic — there's no 'which version do you want?' dialog. The only edge case is intentional hard deletes, which we design as tombstones rather than remove operations.

Ready to talk real-time & collaborative apps?

30-minute scoping call. No obligation, no hard sell.