You push an update to your web demo, and a returning player finds their progress gone. Not lost in a crash, just gone, after an update meant to make the game better. That is the whole save story in Second Tail's first demo week, told in one line by its solo developer: saves disappeared after every update he pushed to itch, and then it was fixed. What makes that one line useful is everything around it: a tiny audience, a fast fix cycle, and two separate web problems that must not be confused.
At a glance
The source: Second Tail devlog, Sunday Conclusion: the first days after the demo, posted on itch.io on October 25, 2026 by para1992. Every fact below comes from that devlog, except the cover art, from the developer's game page.
The game: Second Tail, a demo on itch.io about two pet rats, Sal and Ben, trying to get home across a city. It went out on a Thursday; the devlog sums up the first days after launch.
The symptom: saves disappeared after every update pushed to itch. A returning player came back and their progress was gone. The devlog's outcome is one word: Fixed.
Not claimed here: no save mechanism, no storage change, no migration step, no count of affected players, no engine version. The devlog states none of those. The load-as-you-play and non-freezing-save changes are separate fixes, not the save-loss fix.
Last verified: November 1, 2026.
A demo launch is a save test, whether you planned one or not
Second Tail went out on itch on a Thursday, and by the Sunday devlog the developer had already shipped five updates, from version 0.2.0 to 0.3.4. The audience was small: about 140 page opens, almost 40 game starts, and five comments. That smallness is the point, not an excuse. The developer writes that almost every comment turned into a fix, and the save bug is first on his list of bugs players found which he would never have found himself. A demo with almost 40 starts still produced the week's most important bug, because those players came back after an update, which his own testing did not do.
That is why this bug is so easy to miss in your own project. A developer's own playthrough usually starts fresh, plays the new build, and ends. It never crosses the boundary that matters here: an old save, a new build, and a return visit. If you only test fresh playthroughs, the update path is untested, no matter how many hours you put in. The developer's summary makes the same point in plainer language: ten minutes from a real player is worth twenty of his own playthroughs. A real player brings a history with the game; a fresh playthrough does not.
Two web problems, not one
The second lesson is discipline about what not to merge. The save disappearance sits under a heading about bugs players found. The web build getting lighter sits under a different heading, and it describes a different problem: the web version weighed almost 200 MB, and not everyone waited for it to load. The stated changes there are that chapters now load as you play, and music and textures are better compressed. Nothing in the devlog says the lighter build is what fixed the saves, and this article does not say so either. Treating a smaller download as a save fix would invent what this thin source does not say.
The same care applies to a third, nearby claim: saving no longer freezes the game, and areas are now prepared in small steps. That is about a freeze during saving, not about progress surviving an update. A save that freezes and a save that vanishes after an update are different failures, and the devlog keeps them apart. The rest of the tester-found list shows how broad a small audience's catch can be: a fullscreen button error, a Safari warning, a partly visible vendor, and carrier bars covering Sal. None of those is the save case, and all are the same kind of evidence: real players, on real devices, doing things the developer did not do.
What to reuse
Nothing below is presented as what the Second Tail developer did beyond the fixes already described; the checklist generalizes this devlog for your own project. The reusable habit is testing the update path as its own path, with its own save, instead of assuming a fresh playthrough covers it. It is also keeping separate problems separate in your own notes: a save that disappears, a build that is too heavy, and a save that freezes are three entries, not one vague web problem. The developer works alone after a day job, and still shipped five updates in the first days. A bug reported by a tiny audience was fixed while that audience was still around.
What to do Monday morning
Build a test save, push a new build, and load that old save. Test the update path, not just a fresh playthrough.
Repeat the update-path test on a second device or browser. The players who found this bug were not all on the developer's setup.
Keep three separate notes: saves disappearing after an update, a build too heavy to wait for, and saving that freezes. Verify each on its own evidence.
Before calling a web build lighter, measure what a returning player waits for, not just total size. Loading chapters as you play differs from a smaller download.
Invite a few real players early, even a tiny audience, and give them a way to report. Almost 40 starts and five comments surfaced the week's top bug.
When a tester reports a save problem, ask which boundary it crossed: fresh play, return visit, or return after an update. That decides which path to reproduce.