Thanks for sharing that perspective! I agree that starting with offline reads and queued writes is a practical approach for v1. For SQLite migrations, I’d prioritize versioned migrations and data integrity checks to protect existing user data as the schema evolves. I’d also test upgrades from older versions carefully to catch issues before they reach production. CRDTs can come later when real-time collaborative editing actually demands them.

Agreed, and that's roughly where we landed. Reads are fully local, writes go through an outbox with a visible status, and two devices editing the same entry merge field by field rather than whole-record last-write-wins. Two parents logging overlapping sleeps is surfaced as a conflict for a human to settle, since that's a real disagreement rather than a merge problem. No CRDTs. Our data is mostly per-person entries, so field-level merging was enough.

On migrations: yes. Our first schema shipped column names the next version didn't use, and upgraded phones failed every write. Now every shipped schema is a frozen snapshot, each change gets its own upgrade step, and a test upgrades every old version to the current one before anything ships.