The Fallback That Outlived Its Purpose
A page on my site spent weeks rendering the wrong data, and at no point did anything look broken.
A page on my site spent weeks rendering the wrong data, and at no point did anything look broken.
The page lists project entries. When I first built it, the content pipeline that was supposed to feed it didn't exist yet, so I hardcoded a small array of placeholder entries directly into the source to get the layout right. Entirely standard. Then I built the pipeline. Then I wrote a dozen real entries. Then I moved on to the next thing.
The page kept reading the array.
Nothing errored. Nothing 404'd. The build passed, the page rendered, the cards looked correct. I only found it because I went looking for something else entirely and noticed the page was missing an entry I was certain I had written.
Why fallbacks are uniquely good at hiding
A broken integration announces itself. It throws, it times out, it returns an empty list and the page goes blank and you fix it that afternoon. A stale fallback is the failure mode that renders successfully — and successful rendering is the only signal most of us actually check.
Three properties conspire to make it invisible.
It was correct when you wrote it. There is no bug to find. The code does exactly what it was designed to do. It just outlived the condition that made the design right.
It produces plausible output. Placeholder data is, by construction, shaped like the real thing. That's the whole point of it. So it passes every eyeball test you'd apply while working on something adjacent.
You are the wrong person to catch it. You know what the page is supposed to say, so you read what you expect rather than what's there. The gap only becomes visible to someone who comes to the page cold, or to you, months later, looking for something specific.
The check I'm adopting
The lesson isn't "don't write fallbacks." Fallbacks are how you make progress before every dependency exists. The lesson is that a fallback is a temporary structure and needs to be treated like one.
Two rules, both cheap:
Make the fallback loud. If a component drops to placeholder data, it should say so — a console warning at minimum, ideally something visible in a non-production build. A silent fallback is a lie the system tells you in your own handwriting.
When you finish the real source, grep for the temporary one. The moment a pipeline goes live is the moment its placeholder becomes dangerous, and it is also the only moment you will ever remember the placeholder exists. Closing that loop takes thirty seconds. Not closing it cost me weeks of a page quietly misrepresenting my own work.
This isn't only a code problem
Once I named the pattern I started seeing it everywhere outside the repo. A weekly report still pulling from the manual spreadsheet that the automated one replaced. A dashboard reading a seeded table. An onboarding document describing a process that was superseded two quarters ago, still being handed to every new person because it renders fine — it's a document, it always renders fine.
The general form: wherever you built a stopgap so the real thing could be built, verify the switch actually happened. Systems don't tell you when they're reading the wrong source. They only tell you when they can't read anything at all.