Same Person, Many Devices: Handling Offline Conflicts in Your Vibe Project

You edit a to-do on your phone, open your laptop, and the edit is gone. You write half a note offline on a tablet, go online, and an older version overwrites it. The user did nothing wrong. Your sync rule made a decision on their behalf, and it chose badly. This guide covers one case only: the same account, the same person, on several devices, with offline edits colliding. Multi-user collaborative editing and whole offline-architecture choices are out of scope; the boundary section at the end explains the split.

1. What a conflict actually looks like

Single-user multi-device conflict is yesterday-you versus today-you fighting over the same record. The three usual collisions are worth naming. First, timing skew: the phone edits a list offline on the subway while the laptop edits the same list online; when the phone reconnects, both sides believe they are newest. Second, broken handoff: a note half-written on a tablet never syncs before the lid closes, and the laptop continues it later, so a last-write-wins rule silently eats the tablet half. Third, delete versus edit: one device deletes a record while another edits it offline, and on sync the system casually picks whether the record lives or dies.

The shared root cause is a rule, not a user error. A rule that says only last-write-wins will lose data eventually; a rule that asks the user every time will train them to click blindly. So the first step is not code. It is a decision table: for each data type, write down what happens on collision, then make code execute that table.

2. Four principles before any code

First, never silently lose data. No sync may overwrite something the user wrote without a trace; an overwritten version must remain recoverable, even if only for seven days. Second, decide per field, not per record. A note's title and body are separate fields: if the phone changed the title and the laptop changed the body, that is not a conflict at all, and both changes should survive. Only when both sides changed the same field is a decision needed. Third, deletion is an edit. Deletion should first become a tombstone carrying the deletion time and device, and only be physically cleaned up after every device confirms receipt; deleting outright is the leading source of lost data. Fourth, do not trust device clocks. A phone clock can be changed by hand and can jump across time zones, so deciding by local timestamps hands the verdict to the least reliable witness. Use version numbers plus a per-device operation counter instead.

3. A decision table by data type

One table beats ten scattered if-statements. Start with this one and only add special cases, never leave a row blank. Counters, such as streaks, merge by adding increments from both sides rather than taking the maximum. Toggles and single-choice fields follow the latest human action, ordered by operation sequence rather than clock time. Short text fields in conflict go to a manual pick: show both versions side by side, let the user choose, and keep the loser in history. Long text merges paragraph by paragraph, and only falls back to a manual pick when the same paragraph collides; never overwrite a whole document. List order uses fractional position scores instead of array indexes, because one insert or delete scrambles indexes, while a score can always take a midpoint between two items. Files and images never merge: keep both copies, rename them clearly, and let the user delete one. Delete-versus-edit defaults to keeping the edit and suspending the deletion with a prompt, because wrongly deleting costs far more than keeping one extra record.

The table's value is testability: every row maps to a test case, not to a vague hope. Put it in the spec and get product, engineering, and QA to sign it before implementation; that prevents half the later arguments.

4. A minimal data model: six fields

A solo project does not need a heavy collaboration framework. Give every record six fields: a globally unique record id, a device id naming where the change came from, a base version saying which version the change was based on, a per-device operation counter that only increases, an updated-at timestamp used for display and debugging but never for decisions, and a deleted flag distinguishing deleted from non-existent. On sync, the server compares the client's base version with its current version. Equal means nobody jumped the queue, so accept it; unequal means a collision, so decide by the table, not by timestamp. Device id plus operation counter also makes debugging readable: you can see that a change was the phone's third operation and the laptop's fifth, instead of guessing.

When briefing an agent, write it plainly: every record must carry these six fields, writes missing a field are rejected, and the sync response must state one of accepted, merged, or awaiting manual decision. An interface that only returns success is where silent data loss breeds.

5. The sync flow in five steps

Step one, write locally while offline. Every action lands in the local database first, and the interface must honestly show unsynced rather than pretend it is saved; closing the lid or killing the app must not lose data. Step two, pull before pushing when back online. Fetch the server's latest version, decide locally, then push the result; pushing first lets the local stale version overwrite the server's newer one. Step three, decide locally. Auto-merge what the table allows, and turn the rest into awaiting-decision records without picking a side. Step four, push and confirm. Only when the server returns a new version number does the client clear the unsynced mark; without confirmation, treat it as unsynced and retry, with idempotency keys so a retried push never double-counts. Step five, tell the user. Auto-merged changes deserve only a quiet note; awaiting-decision items deserve a visible entry point the user can open to choose.

6. The conflict screen: three chances

A manual decision screen must do three things at once: be readable, be quick, and be reversible. Readable means showing both versions with differences highlighted, not two timestamps for the user to guess between. Quick means offering keep phone version, keep laptop version, and keep both as three buttons, not forcing copy and paste. Reversible means the losing version goes into history and can be restored within seven days; a choice without an undo makes one misclick destroy trust permanently.

The classic bad example asks, "Conflict detected. Overwrite?" without saying which side would win, so the user clicks on luck. The opposite bad example asks about everything, including title changes that could auto-merge, so by the third dialog the user clicks OK blindly and the one conflict that matters slips through. Restraint in the interface and strictness in the table are two sides of the same coin.

7. Eight test cases before launch

Run these eight before shipping. Phone edits a title offline and laptop edits the body online; after sync, both must survive. Phone and laptop each edit the same title offline; sync must produce a manual choice, not an automatic loss. Tablet deletes a record offline while the phone edits it online; the record must survive with the deletion suspended and flagged. The phone clock is set a year forward and syncs; the decision must not change. One record is edited offline in turn on three devices; after all reconnect, the result must converge. A sync interrupted mid-push and retried must not double-count. A user who picks wrong in a manual choice can restore from history within seven days. An old client connecting to a new server gets a readable rejection for writes missing a field. Do not excuse a failing case with "users rarely do that"; they will.

8. Six anti-patterns to fix on sight

Last-write-wins without history is the most expensive anti-pattern: the code saved is repaid many times over in support tickets and bad reviews. Using device clocks as the verdict breaks the moment someone travels across time zones. Deleting physically creates resurrection-or-loss dilemmas the moment an offline device returns. Silently retrying a failed sync forever lets users believe data is saved until they switch devices. Asking the user about every conflict transfers the cost of missing rules onto them. Finally, testing sync only on one device guarantees the first multi-device users will teach you the lesson in production.

9. Launch checklist

Does the decision table cover every data type, with no row left as to be decided? Does deletion always go through tombstones, with cleanup only after all-device confirmation? Does the sync interface return accepted, merged, or awaiting-decision? Does retrying a push carry idempotency protection? Is the conflict history retention period written into the product notes? Did all eight test cases pass and get filed? Check all six before giving sync to your first real users; missing even one, fix it first, because the reputational cost of losing sync data far exceeds a week's delay.