My app uses optimistic updates (the UI updates instantly before the server confirms) to feel fast. I've never audited what happens when the server rejects the change or the request fails. Audit my optimistic UI patterns: 1. Find every optimistic update: likes, toggles, cart changes, message sends, list reorders, settings that apply instantly. For each one, trace what happens when the request fails, times out, or returns a validation error. 2. Check rollback correctness: does each failure restore the exact prior state, including related UI (counts, totals, derived lists)? A like that stays lit after the server rejected it, or a deleted item that reappears in the wrong position, is the usual bug. 3. Check conflict handling: what happens when two optimistic changes race (toggle on, toggle off, first request resolves last)? Do I key responses to the action they belong to, or can a stale response resurrect wrong state? 4. Check error communication: when a rollback happens, does the user get told their action didn't take, or does the UI silently revert and leave them believing it worked? Silent reverts cause real harm on consequential actions (they think they saved, they didn't). 5. Draw the line on what shouldn't be optimistic: payments, destructive actions, permission changes, anything irreversible or money-adjacent should show real pending states, not fake success. Flag any of these that are currently optimistic. Don't remove optimistic updates that work; they're worth keeping. The deliverable is the per-action audit, rollback fixes, conflict handling, honest error states, and the list of actions you've moved from optimistic to confirmed (with the reason).