Autosave Works. Until the Restored State Is Invalid.

Autosave feels like a solved problem. You serialize the state. You store it. You restore it. Users don’t lose their input. Everyone’s happy. That’s what I believed too. Until I realized something uncomfortable: The last saved state is not always a safe state. Saving Is Easy. Restoring Is Not. Autosave is straightforward: serialize state store it in localStorage (or IndexedDB) reload it on startup In most cases, that’s good enough. But here’s the nuance that changed how I think about client-side persistence: There’s a big difference between: “This is the latest snapshot.” “This is a valid state for the application.” They are not the same thing. And most implementations quietly assume they are. A Concrete Example: Multi-Step Onboarding Imagine a multi-step onboarding flow: Account information Preferences Payment details Success → profile created Behind the scenes, the state evolves at every step. Now imagine this: The user completes payment details. A derived field recalculates something