Collaborative editing is one of those technical choices that looks simple from the outside and becomes very nuanced once you build a real product around it.
A common question is: why not use CRDTs?
CRDTs are a powerful approach to collaboration. They are especially attractive for local-first software, offline editing, peer-to-peer synchronization, and systems where multiple replicas need to merge changes automatically without a single central authority deciding the final order of operations.
Aamu.app takes a different approach.
Aamu.app uses ShareDB, which is based on Operational Transformation, often shortened to OT. In our architecture, collaboration is server-authoritative: clients can edit optimistically, but the server is the source of truth. The server validates, orders, applies, stores, and broadcasts changes.
This is not because CRDTs are bad. They are not. It is because Aamu.app is not just a document editor.
Aamu.app is a full workspace.
Documents live next to tasks, email, helpdesk, meetings, databases, forms, files, comments, permissions, automations, search, AI features, and team-level workflows. In that kind of product, the hardest problem is not only merging text edits. The harder problem is keeping the whole workspace consistent.
The core tradeoff
CRDTs are excellent when the primary goal is distributed editing.
They are designed for situations where different users, devices, or replicas may edit the same data independently and later synchronize their changes. In an ideal CRDT-based system, users can keep working even without a stable connection, and the system can merge concurrent changes automatically.
That is a very attractive model.
But Aamu.app optimizes for a different set of constraints:
clear permissions
predictable business logic
auditability
integration with other workspace objects
reliable automations
consistent search and AI indexing
a single source of truth for team data
For those constraints, a central server is often the simpler and safer architecture.
Aamu.app is more than collaborative text
In a standalone document editor, the main question may be: how do we merge document edits?
In Aamu.app, the question is broader: how do we keep the entire workspace correct when a document edit may affect other parts of the system?
A comment might become a task.
A document might be linked to a customer conversation.
A database row might reference a file or a helpdesk ticket.
An AI command might turn text into an action.
A permission change might immediately affect who is allowed to see or edit something.
A search index or Team Brain feature may need to update when content changes.
An automation may need to run exactly once when a specific event happens.
In this environment, collaboration is not only a sync problem. It is also a domain logic problem.
A server-authoritative model gives us a clear place to answer important questions:
Is this user still allowed to make this change?
What is the canonical order of changes?
Which version of the document did this change apply to?
What other objects should be updated because of this change?
Should an automation run?
Should search or AI indexes be refreshed?
What should be written to the audit log?
What should other users see next?
With ShareDB and OT, the server can decide these things in one controlled flow.
Permissions are simpler with a central authority
Permissions are one of the strongest reasons to prefer a central server in a business workspace.
Imagine a user opens a document, goes offline, and keeps editing for an hour. During that time, an admin removes their access to the workspace, the project, or the document.
What should happen when the user comes back online?
In a CRDT-first architecture, the system may have technically valid changes that can merge cleanly with the document. But from the business point of view, those changes may no longer be allowed.
That does not mean CRDT systems cannot handle permissions. They can. But permission handling becomes a separate and often difficult layer on top of the sync model.
In a server-authoritative model, the rule is more direct: the server validates every accepted change. If the user no longer has permission, the change is rejected.
For Aamu.app, that simplicity matters.
Teams need collaboration, but they also need access control they can trust.
Business events should happen exactly once
A document edit is sometimes just a document edit.
But in Aamu.app, a document edit can also be part of a larger workflow. It might trigger an automation, update an activity feed, create a notification, refresh an AI context, or connect to another object in the workspace.
These side effects should not happen “eventually, maybe, after merge resolution, depending on which replica sees what first.”
They should happen exactly once, based on an accepted server-side event.
This is another reason why a central server works well for Aamu.app.
When the server accepts an operation, it can also decide what else should happen. It can update related records, queue background jobs, send notifications, and record activity in a predictable order.
That makes the product easier to reason about, easier to debug, and easier to operate.
Auditability matters in team software
Aamu.app is built for teams and businesses. In that context, it is useful to know what happened and when.
A server-authoritative OT model gives us a simple history:
operation accepted
document version updated
user recorded
timestamp stored
related events triggered
other clients notified
This linear accepted history is valuable.
It helps with debugging. It helps with restoring data. It helps with understanding user actions. It helps with support. It also makes it easier to build features such as activity feeds, version history, notifications, and audit logs.
CRDT systems can also keep history, but the mental model is different. The system may contain distributed operations from multiple replicas that converge into the final state. That is powerful, but it can be harder to explain and operate in a business workspace where customers expect a clear source of truth.
Offline-first is not our main product promise
One of the biggest advantages of CRDTs is offline-first editing.
If the main promise of Aamu.app were “edit everything fully offline and sync later,” then CRDTs would be a very natural choice.
But that is not the main promise of Aamu.app.
Aamu.app is designed to reduce the fragmentation of work. The goal is to bring common team workflows into one consistent workspace: tasks, docs, email, helpdesk, meetings, databases, files, forms, and AI-assisted actions.
That kind of product benefits from being connected to the server, because the server is where the team context lives.
Search, permissions, automations, notifications, AI features, integrations, and cross-object workflows all depend on having a reliable shared backend.
We may still support local drafts, temporary offline resilience, and optimistic editing where it makes sense. But full local-first collaboration is not the central design goal.
OT is a good fit for our needs
Operational Transformation has a long history in collaborative editing. The basic idea is that users can make concurrent edits, and the system transforms operations so they can be applied in a consistent order.
ShareDB gives Aamu.app a practical foundation for this model.
With ShareDB, we get:
real-time synchronization
optimistic local editing
server-side ordering of operations
a canonical document state
integration with our existing backend
a clear place for validation and authorization
a model that fits well with other server-side business logic
For Aamu.app, this is a good tradeoff.
It keeps collaboration fast enough for users while keeping the backend understandable and authoritative.
Why not use both?
It is possible to combine ideas from both worlds.
A product can use CRDTs for some local-first data, OT for document editing, server-side events for business workflows, and traditional database transactions for core records.
But every additional data model has a cost.
Aamu.app already combines many parts of work into one product. Adding a CRDT layer would not only mean changing the editor sync model. It would affect storage, migrations, permissions, version history, indexing, automations, testing, backups, and support.
That complexity has to pay for itself.
For now, the benefits of CRDTs do not outweigh the operational simplicity and product consistency we get from ShareDB and a central server.
The real design principle: one source of truth
The deeper decision is not “OT vs CRDT” in isolation.
The deeper decision is this:
Aamu.app is built around one shared workspace, not disconnected local replicas.
That means the system needs a trusted source of truth.
The server is where permissions are checked.
The server is where operations are accepted.
The server is where related workflow events are created.
The server is where search and AI context can be updated.
The server is where the team’s shared state becomes real.
CRDTs are excellent when the product vision is local-first independence.
Aamu.app is optimized for connected team workflows.
That is why a central server and ShareDB/OT fit the product well.
The tradeoff we accept
This architecture does have tradeoffs.
A central server means that full offline editing is harder. It means collaboration depends on the backend being available. It means we need to operate the server reliably and keep latency low.
Those are real costs.
But in return, we get a simpler and more predictable model for the things that matter most in Aamu.app:
permissions
consistency
auditability
workflow automation
AI integration
cross-object relationships
server-side validation
reliable team collaboration
For a business workspace, those properties are more important than full peer-to-peer or offline-first editing.
Conclusion
CRDTs are an impressive technology, and they are the right choice for many collaborative and local-first applications.
Aamu.app chooses a different path.
Because Aamu.app is a full workspace rather than just a document editor, we care deeply about server-side correctness, permissions, audit logs, automations, search, AI context, and consistency across many types of work.
ShareDB and Operational Transformation give us a collaboration model that fits that product vision.
The result is a system where editing can feel real-time and responsive, while the server remains the trusted place where team data is validated, ordered, connected, and made consistent.
In short:
CRDTs are great for distributed editing.
A central server with ShareDB/OT is a better fit for Aamu.app’s connected workspace.