Cairn — Coordination That Survives Outages

What happens when the internet disappears, but the work still needs to get done?

Cairn is an offline-first coordination system designed to help teams manage incidents, tasks, and resource requests even when connectivity is unavailable. Instead of treating offline mode as a read-only fallback, Cairn is built around a simple principle: coordination should not stop just because the network does.

The Problem

Connectivity failures can disrupt coordination precisely when teams need a shared understanding of what is happening. Field teams, campus operations, event organizers, community responders, and other groups may still need to assign tasks, track requests, and pass updates between devices.

Most connected workflows are designed around the assumption that a reliable network will be available. Cairn explores a different approach: keep operational state on the device, enable offline information exchange, and preserve conflicting updates instead of silently overwriting them.

What We Built

1. Work without the internet

Cairn stores incidents, tasks, resource requests, and timeline entries locally using IndexedDB. Its progressive web app architecture supports a cached application shell, while local data remains available for continued work.

Users can create and update tasks, record requests, and review the incident timeline without requiring a server for those operations.

2. Relay operational state through QR codes

Cairn's QR Relay turns local changes into a validated, versioned payload that another device can scan and import. A paste-based fallback supports situations where camera access is unavailable.

The receiving device validates the payload, deduplicates changes, and merges new information into its local records. The transfer itself does not require a server connection.

3. Detect and resolve conflicting offline changes

Two devices may independently update the same task while disconnected. Cairn detects incompatible changes and presents them for explicit resolution instead of silently choosing the last update.

Both original changes are preserved. The selected resolution is recorded, the resulting state is persisted locally, and the timeline retains an audit trail of conflict detection and resolution.

4. Generate a Local Brief

Cairn can generate a concise incident handover from the actual recorded state. It summarizes the situation, completed tasks, outstanding work, open requests, next actions, and uncertainties.

The submitted experience uses deterministic local summarization. The brief runs on the device, requires no API credits, and does not send incident data to an AI service. An optional server-side OpenAI integration was also implemented, but live AI generation is not enabled in the current demo.

How We Built It

Cairn was developed with React, TypeScript, Vite, and Tailwind CSS, using IndexedDB for local persistence and a progressive web app architecture for offline access. QR generation and scanning use the qrcode and jsQR libraries. The relay and conflict logic are supported by a deterministic Vitest test suite.

We built the application in stages: first the local-first foundation, then QR-based state transfer, then conflict-aware merging, and finally local incident summarization. This incremental approach helped preserve working functionality while adding more demanding behavior.

The Hardest Challenges

The challenge was not simply displaying an offline badge. The application needed to keep accepting changes locally, transfer those changes between devices, reject malformed payloads, ignore duplicate imports, and reconcile competing updates without destroying history.

Conflict handling required particular care. A valid merge should not manufacture conflicts between compatible updates, but it must not hide genuine disagreement either. Cairn therefore uses explicit conflict detection, durable conflict records, and user-selected resolutions.

We also wanted the handover feature to remain useful without paid services. Making the Local Brief a deterministic, on-device operation means the core experience does not depend on API credits or network availability.

What We Learned

Offline-first software is more than caching a website. It requires deliberate decisions about local persistence, identity, change tracking, deduplication, merge behavior, and unresolved state.

We also learned that useful technical complexity should remain visible to the user only when needed. Cairn's conflict resolution is built on a history of changes, but the user sees a clear choice about which outcome to keep.

At the final development verification, 93 automated tests passed, with TypeScript checks and the production build completing successfully.

What's Next

Future work could extend Cairn with more advanced synchronization between devices, stronger end-to-end security review, broader accessibility testing, and larger offline transfer support.

The long-term vision is a practical coordination layer for environments where connectivity is unreliable—not another dashboard that becomes unavailable when the network does.

Cairn: keep the work moving, even when the internet stops.

Built With

  • api
  • bolt-database
  • bolt.new
  • edge-functions
  • indexeddb
  • jsqr
  • openai
  • progressive-web-app
  • qr-code
  • qrcode
  • react
  • service-workers
  • tailwind-css
  • typescript
  • vite
  • vitest
Share this project:

Updates

Submission history