Two People, One Document, Zero Conflicts
The system makes sure they don't overwrite each other.
The Architecture Series · 8 minute read · By Ed | Founder & CEO, DealiOS
Google Docs lets two people type in the same paragraph at the same time. That's a technical marvel. It's also, for professional sales documents, a terrible idea.
A proposal written by two people simultaneously reads like it was written by two people simultaneously. The voice shifts mid-paragraph. The argument contradicts itself between sections. The opening sets up a problem that the conclusion doesn't solve because someone else wrote the conclusion.
A proposal written by two people simultaneously reads like it was written by two people simultaneously.
Real-time collaboration solves a technical problem (concurrent editing) while creating a human problem (incoherent output). For chat messages and meeting notes, the tradeoff works. For a $500,000 enterprise proposal, it doesn't.
The Coherence Problem
Picture the scene. Two people are editing a proposal at the same time. Writer A is building a case for ROI in the executive summary. Writer B is adding technical specifications in the scope section. Writer A references the technical section that Writer B hasn't finished yet. Writer B reorganizes the specs into a different structure, breaking Writer A's reference. Both are doing good work. Both are moving fast. The document is getting worse with every keystroke.
This isn't a theoretical failure mode. It's the daily reality of every team that uses real-time collaborative editing for high-stakes documents. The technology works flawlessly. Character-by-character synchronization. Conflict-free replicated data types resolving every edit in real time. Operational transforms ensuring both writers see the same state. The engineering is impressive.
The output is wildly incoherent.
Real-time collaborative writing is like two people trying to drive the same car at the same time. One's steering left. One's steering right. The car technically moved. Just not anywhere useful.
The problem isn't the technology. The problem is the assumption that professional document creation benefits from simultaneous contribution. That assumption holds for some content types and fails catastrophically for others, and the failure is hardest to see because the document looks complete. It has an introduction. It has sections. It has a conclusion. It just doesn't have a voice. And voice is the invisible infrastructure of a persuasive document.
A great proposal reads like one person thought deeply about your problem and crafted a solution. It has an argument that builds. Evidence that accumulates. A perspective that's consistent from the first sentence to the last. That consistency is what separates a document that closes a deal from a document that gets forwarded to the "pending" folder where deals go to die quietly.
You can't get that consistency from two simultaneous writers any more than you can get a coherent novel from two authors typing alternate chapters in real time. The novel would have characters who change personality between scenes and a plot that contradicts itself. The proposal does the same thing, just with pricing sections instead of plot points.
Presence, Not Locks
So if real-time collaboration is the wrong model, what's the right one?
Not hard locks. Hard locks are the opposite extreme, and they fail for different reasons. A hard lock says "this document is checked out to Sarah. Nobody else can edit." That's technically safe. It's also operationally hostile. Sarah stepped away for lunch. The deal review is in 45 minutes. The lock expires in two hours. Now the team is blocked on infrastructure instead of blocked on content.
The middle ground is presence with soft coordination. Supabase Realtime broadcasts who's currently in a document: userId, displayName, joinedAt. Everyone can see who's working. No hard locks. Two people can edit simultaneously if they choose to. But they can see each other. And that visibility changes everything.
When you open a document and see "Sarah is editing," you make a choice. Maybe you wait. Maybe you message Sarah: "I need to update the pricing section, let me know when you're done." Maybe you jump in anyway because you're working on a completely different section and the overlap risk is low. The point is: you made an informed decision. The technology provided visibility, not enforcement.
Hard locks feel controlling. Presence feels informative. Both achieve the same result (people take turns) through different mechanisms. One generates compliance. The other generates cooperation. Cooperation works better in professional contexts where autonomy matters, because professionals don't like being told they can't access their own documents.
The implementation is lightweight. Supabase Realtime presence broadcasting with auto-cleanup on unmount. When a user leaves the document (navigates away, closes the tab, disconnects), their presence is automatically removed. Self-presence filtering ensures you don't see your own name in the "currently editing" list. The entire system is a few dozen lines of code that provide a social layer on top of a document layer.
The social layer is the point. Humans are remarkably good at coordinating when they have information. We've been taking turns since kindergarten. We don't need a workflow engine to manage it. We just need to know who else is in the room.
The Voice Argument
A great proposal has one voice. One perspective. One narrative arc. That's not a technical constraint. It's a quality standard.
Ask any editor: the fastest way to ruin a document is to let three people write it at the same time. The fastest way to improve a document is to let one person write it and three people review it. The creation phase benefits from singular focus. The review phase benefits from diverse perspective. These are sequential activities, not simultaneous ones.
Drafts should be sequential. Reviews should be parallel. Most collaboration tools get this backward.
Drafts should be sequential. Reviews should be parallel. Most collaboration tools get this backward.
The sequential draft means one person owns the voice. They make every word choice, build every argument, establish every rhythm. The document reflects a single mind's engagement with the problem. That's not gatekeeping. That's craft. A client reading the proposal doesn't need to know how many people contributed. They need to feel like one expert understood their problem deeply.
The parallel review means multiple people can comment, suggest, and flag issues simultaneously. Comments don't break voice. Track changes don't break voice. Only simultaneous writing breaks voice. The review phase is where diverse perspectives add value without disrupting coherence. "This number doesn't match the SOW" is a parallel-safe contribution. Rewriting the executive summary while someone else is rewriting the pricing section is not.
This maps to how high-performing teams actually work. The best proposal teams have a primary author and a review committee. The primary author drafts. The committee reviews. Nobody edits the same section at the same time because everyone who's been through the process knows what happens when they do: the document turns into a committee memo. And committee memos don't close deals. They close eyes.
When Real-Time Wins, When It Loses
Real-time collaboration isn't categorically bad. It's contextually inappropriate for certain content types.
Real-time wins for: Meeting notes. Brainstorm docs. Kanban boards. Chat. Project plans. Bug trackers. Anywhere the content is additive and voice doesn't matter. Three people can add items to a shared shopping list without coordination issues. Three people can log meeting action items simultaneously. The content is atomic (each contribution stands alone), and coherence across contributions is irrelevant.
Real-time loses for: Proposals. Contracts. Executive summaries. Presentations. Investor updates. Customer-facing reports. Anywhere coherence determines quality. These documents tell a story, make an argument, build a case. The narrative thread that connects Section 1 to Section 5 is the entire point. Break that thread and the document fails, regardless of how excellent each individual section is.
The diagnostic question is: "Does the quality of this document depend on voice consistency across its parts?" If yes, sequential drafting beats simultaneous editing. If no, real-time collaboration is fine.
Most collaboration tools don't ask this question. They apply the same model (Google Docs-style CRDT-based real-time editing) to every document type. It's the same mistake as using one status dropdown for two state machines (Library #19). The tool treats all documents as equivalent when the documents themselves are categorically different.
The architectural choice is deliberate: no CRDT implementation. No operational transforms. No character-by-character synchronization. Instead, presence awareness and a conscious bet that social coordination produces better outcomes than technological enforcement for professional documents.
It's the choice to not build the technically impressive thing. And it took more confidence to make that choice than it would have taken to build the CRDT.
The Implementation Details That Matter
The presence system is simple. The design decisions behind it are not.
Auto-cleanup on unmount. When a user navigates away from a document, their presence is removed immediately. Not after a timeout. Not after a heartbeat fails. On unmount. Because stale presence is worse than no presence. If Sarah closed her tab 20 minutes ago but her name still shows as "editing," the presence system is lying, and lying presence erodes the exact trust the system is supposed to build.
Self-presence filtering. You don't need to see your own name in the "currently editing" list. You know you're here. Showing your own presence adds visual noise without information value. Filter it out. The presence list answers one question: "who else is working on this right now?" The word "else" is the design constraint.
No presence history. The system doesn't show "Sarah edited this 3 hours ago." That's activity logging, not presence. Presence is real-time occupancy. It answers "who's here now?" not "who was here before?" Mixing the two creates confusion about whether someone is currently in the document or was previously in the document, which is the difference between "I should coordinate" and "I can proceed."
These seem like small decisions. They're not. Each one prevents a failure mode that would undermine the system's purpose. Stale presence causes unnecessary waiting. Self-presence causes cognitive clutter. Historical presence causes false coordination signals. Remove all three and what's left is a clean, real-time answer to a simple question: am I alone in this document right now?
The Architectural Insight
The deeper lesson isn't about collaboration models. It's about matching the architecture to the problem.
CRDTs and operational transforms are elegant solutions to a well-defined problem: how do multiple writers edit the same content simultaneously without conflicts? The engineering is beautiful. The algorithms are proven. The implementation is battle-tested across billions of documents.
But the question for professional documents isn't "how do we avoid conflicts?" The question is "how do we produce a document that sounds like one expert wrote it?" Those are different questions with different optimal solutions. The first question is a distributed systems problem. The second is a craft problem. You don't solve craft problems with distributed systems. You solve them with process, visibility, and the humility to let one person hold the pen.
Presence broadcasting isn't a lesser version of real-time collaboration. It's a different solution to a different problem. And recognizing that the problem is different is the architectural insight that matters more than any implementation detail.
There's an irony worth sitting with. The technology that makes real-time collaboration possible (CRDTs, operational transforms, conflict resolution) is among the most sophisticated in distributed systems. Entire PhD dissertations have been written about convergence guarantees and causal ordering. The technology that makes presence-based collaboration possible (a real-time channel broadcasting a list of user IDs) is something a junior developer could build in an afternoon.
The team that builds the CRDT is solving a harder problem. The team that builds presence is solving the right problem.
The sophisticated solution creates worse outcomes for professional documents. The simple solution creates better outcomes. That's not a failure of engineering. It's a success of problem identification. The team that builds the CRDT is solving a harder problem. The team that builds presence is solving the right problem. And solving the right problem with simple tools will always beat solving the wrong problem with brilliant ones.
The best architectures aren't the ones that solve the hardest technical problems. They're the ones that correctly identify which problem to solve.
The takeaway: For professional documents where voice consistency determines quality, presence-based soft coordination produces better outcomes than real-time collaborative editing: solving the right problem with simple tools beats solving the wrong problem with brilliant ones.
References
1. Shapiro, M., Preguiça, N., Baquero, C., & Zawirski, M. (2011). "Conflict-Free Replicated Data Types." Proceedings of the 13th International Conference on Stabilization, Safety, and Security of Distributed Systems. 2. Supabase. (2024). "Realtime: Presence." Supabase Documentation. 3. Ellis, C. A. & Gibbs, S. J. (1989). "Concurrency Control in Groupware Systems." Proceedings of the 1989 ACM SIGMOD International Conference on Management of Data. 4. Gentle, S. (2024). "ShareJS and Operational Transformation." josephg.com.
This paper is part of The Architecture Series by Ed, Founder & CEO of DealiOS. For the weekly series and more technical deep-dives, visit dealios.app/library.
See how these principles come together. Explore the platform →