Let me tell you about the bug that made me doubt myself more than any other in this series.

I’d fix something — say, a misheard word in a transcript. I’d save the corrected file to the server. I’d open the app on my phone to admire the fix. And the old, wrong word would still be sitting there. So I’d fix it again. Save again. Still wrong. I started to wonder if I’d forgotten how to edit a text file.

I hadn’t. The fix was right every time. The problem was never my change. It was caching — and if you build web apps, it will cost you hours until you learn to spot it.

The confusing thing isn’t a broken fix. It’s a working fix that doesn’t show up, because somewhere between your server and your eyes, an old copy is being served. You can “fix” the same thing five times and see no change — not because you’re wrong, but because you’re looking at an old copy.

Step One: Prove the Fix Is Actually There

The thing that finally helped was learning to stop trusting my eyes and check the source.

When the corrected word kept showing wrong on my phone, I asked the right question: is the wrong word still in the actual file on the server? I checked. It wasn’t. The file was correct. The fix was real.

That one check splits the problem cleanly in two:

  • If the wrong content is still in the source file → it’s a content problem. Keep editing.
  • If the wrong content is gone from the source but still shows on screen → it’s a delivery problem. Stop editing; something is serving an old copy.

Once I’d confirmed the source was right, I knew the enemy wasn’t my fix. Something was handing my phone an old copy. Now the hunt had a target.

Where Old Copies Hide (It’s Layers)

Here’s what took me a while to understand: caching isn’t one thing in one place. A web app has several separate layers, and any one of them can serve you an old version while the others are perfectly up to date. That’s why it’s so confusing — you clear one and the old copy survives in another.

The layers I learned to suspect, roughly from your eye backward:

  • The browser cache. Chrome holds onto files so pages load faster. Great for speed, unhelpful when you just changed those files.
  • The PWA / “installed app” cache. When you install a web app to your home screen, it often keeps its own offline copy that can be stickier than the browser’s. This is why deleting and reinstalling didn’t even fix my app’s icon — the old one kept coming back.
  • The CDN cache. I serve everything through Cloudflare, which keeps copies at the edge so my little home server isn’t hit too hard. Helpful — until the edge is still handing out last week’s file.
  • The app’s own data cache. My app stored transcript data on the phone for speed, so even with every other cache cleared, it could still read its own old copy of the text.

My corrected word — and, it turned out, even that 20-minute-off search result — were old copies hiding in these layers. Clearing the right one fixed the playback spot right away. The fix had been correct the whole time.

“Clear the Cache” Is a Band-Aid, Not a Cure

For a while my fix was the usual folk remedy: clear the browser cache, clear site data, reinstall the app. Sometimes it worked. Sometimes — as my notes from those nights plainly say — clearing the Chrome cache didn’t work.

And even when it does work, it’s the wrong fix, because you can’t ask your users to clear their cache. An eighty-year-old man with a tablet is not going to dig through Chrome settings. If the only way to see my updates is to clear the cache by hand, the app is broken for everyone but me.

The real cure is to make fresh content arrive on its own:

  • Cache-busting — when a file really changes, give it a new name or a version stamp, so the browser treats it as new instead of reusing the old one.
  • Honest cache headers — tell each layer how long it’s allowed to hold something. Cache the things that rarely change for a long time; tell it to always re-check the things that do.
  • Service-worker updates — for the installed-app layer, build in logic that notices a new version and swaps it in, instead of keeping the offline copy.
  • CDN purge / rules — when I push a real change, the edge cache needs to let it through.

The goal is simple to say: the user should never have to do anything to see the latest version. Getting there is most of the work.

The Web App’s Honest Limit

One more scar worth showing. A children’s app I’d built ran fine on a tablet for months — then one day, suddenly, playback failed. Nothing in my code had changed. A browser update had changed the rules underneath me.

That taught me a real trade-off. I like web apps. They install with no app store, update without anyone’s approval, and run on almost anything. But they sit on top of a browser and an operating system you don’t control, and when those change, a working app can break overnight through no fault of your own. As I wrote in my notes that night: if a Chrome update can cause this, it can happen again anytime — that’s the limit of a web app. It’s a price I still happily pay. But it’s fair to name it.

The Lesson

If you take one thing from this: when a change doesn’t show up, suspect caching before you suspect your fix. Confirm the source is correct, and if it is, you’re not losing your mind — you’re looking at an old copy. Then go hunt it through the layers.

I didn’t know any of this vocabulary — service workers, edge caches, cache-busting — when I started. I just kept getting fooled until I learned where the old copies hide. The AI wrote the cache headers and the version logic; my job was to spot the kind of bug I was looking at. A good part of debugging is knowing what kind of problem you’re in, and caching is a kind that hides in plain sight.

If these in-the-trenches notes are useful to you, please subscribe — there’s plenty more where this came from.

Key Takeaways

  • A working fix that doesn’t appear on screen is usually a caching problem, not a fix problem.
  • First, confirm the corrected content is actually in the source file — that splits “content bug” from “delivery bug.”
  • Caching lives in layers: browser, the installed-PWA/service-worker copy, the CDN, and the app’s own stored data — any one can serve an old copy.
  • “Clear the cache” is a band-aid; you can’t ask real users to do it. The cure is cache-busting, honest headers, service-worker updates, and CDN purging — so fresh content arrives on its own.
  • Web apps sit on a browser you don’t control: an OS or browser update can break a working app overnight. A real trade-off, worth naming.