The short version: my site passed 71 automated checks and shipped. Three days later I found a bug by clicking through it like a normal person, and it was sitting on the most obvious path in the whole site.
Three days after I launched the rebuilt rodneybuilds.com, I clicked from my own homepage into one of my product pages and landed on a blank screen. Not an error. Not a missing page. Just white.
My first thought was that I had broken something in the last hour without noticing. So I opened the same page directly, by pasting the address into the address bar, and it loaded perfectly. I went back and clicked through, and it was blank again. Refreshing the blank page brought it back. The page existed, the address worked, the content was there, and it only failed when I moved through the site the way a person actually moves through a site.
That is the part that got under my skin. It was not some strange corner of the site that only broke on a Tuesday. It was the main path: land on the homepage, click the thing you came to see. If a stranger had visited that week, this is the first thing they would have hit.
I should say what had happened before that. The site had shipped 3 days earlier with 71 checks passing between the code and the public version. Unit tests, behavior tests, accessibility, performance budgets, link checks, visual comparisons against the approved design. That is a real gate, and it earned its keep. It caught genuine problems before launch. I had watched the whole suite go green and felt like the work was proven.
The cause turned out to be the animation system. Every section on the site fades in as you scroll down to it, and that system set itself up correctly whenever a page loaded fresh. When I moved between pages inside the site, it did not reset the way it needed to. The sections of the new page were all there, sitting at zero opacity, invisible and waiting for a signal that never came.
The tests missed it for a reason that still bothers me, because it is so ordinary. Every check opened a page fresh. That is the sensible way to write a test, and it is exactly the thing a real visitor never does. A real visitor lands somewhere, clicks around, goes back, changes their mind, and treats the whole site as one connected thing. My 71 checks proved that every address on the site worked. Not one of them proved that the site worked as a journey.
This was the message I sent once I realized it was not a one-off glitch. I have cleaned it up slightly so it reads more easily, but it is the same report I filed in the build session.
There are multiple loading issues across the site. For example, if I visit the dedicated page for a shipped product, the product page does not load until I refresh the browser. If I return to the homepage or the previous page, that page also fails to load until I refresh again. This is happening throughout the site, not only on one page. I do not know the cause yet, but the source of the issue needs to be found and resolved immediately.
I am keeping that here because of what it does not contain. I was not reporting a broken component or a failed test, because I had no idea which component was at fault. I was describing a pattern I could see with my own eyes: pages work after a refresh, but not when I move through the site normally. Describing the symptom honestly is what moved the work off “does this page load” and onto the better question, which is whether the site still works when a person walks through it.
The code fix was small once I knew what it was. The observer had to reset when navigation happened inside the app, and after that the product pages stopped depending on a refresh to become visible. The workflow fix is the one I actually care about. A site is not verified until somebody has clicked the main path. Opening each page directly is still worth doing, and it proves exactly one thing: that pages can load on their own. It says nothing about whether the experience holds together.
That is the lesson I am carrying out of this build, and it is not really about animation. AI can make something look finished extremely fast, and a green test suite makes that feeling more convincing than it has any right to be. The only thing that settles it is walking the path a real person is going to walk.
The lesson: a passing test suite tells you the pieces work. It does not tell you the product works. Somebody still has to walk in the front door and try to get where they were going.
The Friday Field Kit
This week’s field kit is verify-like-a-visitor.
It is a skill you can hand to an AI before you trust a website launch, a landing page, a client handoff, or an AI-built preview. It tells the AI to open the real site in a real browser, move through it like a visitor, test the mobile path, watch the console, and keep proof behind every result. If the AI cannot observe something, it has to mark the result NOT VERIFIED instead of pretending it passed.
Get the file: https://rodneybuilds.com/skills/verify-like-a-visitor.md
The short checklist inside it:
Open the site from the homepage.
Reach the important pages by clicking, not by pasting addresses.
Test the main call to action.
Push at least one form, menu, toggle, or control.
Repeat the main path at phone width.
Check for new console errors.
Mark anything without proof as NOT VERIFIED, never PASS.
That is the exact gap from this issue. My 71 checks missed the bug because they opened pages fresh, and this exists so your AI has to test the thing a visitor actually experiences.
Which of your own tests would still pass if the product were broken for a real person? Hit reply and tell me. I read every reply.