Why Cairn works on a train

Most web apps ask the server before they show you anything. That is why a board with two hundred cards takes a second to appear and why a bad connection turns a tool into a wall of spinners. We decided early that Cairn would not do this.

Every workspace is mirrored into the browser. Opening a view reads from that mirror, so it appears in the time it takes to paint. Edits are written locally first, then queued and sent. If the connection drops, the queue waits. When it comes back, the queue drains and the server's changes flow in.

Conflicts are rarer than people expect, because most edits touch different fields of different items. When two people do change the same field, the later write wins and the earlier one is kept in the item's history, where it can be restored with one click. We considered cleverer merges and decided that predictable beats clever.

The practical result is that Cairn feels like a desktop app and survives a tunnel. The engineering result is that the server got simpler: it is a log of changes and a set of permissions, and it does not need to be fast to make the product feel fast.