A page speed score, a saved copy of a theme file, and moving some folders around all looked like small, five-minute tasks from the outside. None of them were. Here are the four that actually surprised me, and what was really going on underneath each one.
Chasing one mobile speed number that wouldn't move
My desktop PageSpeed score dropped from a baseline of 96 down to 51 at one point, and I got it back up to around 91 to 92 with real fixes. Mobile never recovered the same way. It kept dropping every round even when the fixes behind it were independently verified as correct. The working theory is that the automated testing tool never actually fires the real scroll, click, or touch events a real visitor would, so optimizations that only kick in on real interaction never get credit in the test, even though they genuinely help real visitors.
The call I made once the real work was done
Once the desktop score was genuinely back near where it started and the mobile fixes were independently confirmed correct, I made the call that a real visitor's experience mattered more than satisfying an automated test that might not even be measuring what it claims to measure. I stopped chasing that specific mobile number on September 2nd. That's not the same as giving up on speed. It's deciding which number is actually worth chasing once the real work is already done.
Assuming my own saved copy of a theme matched what was actually live
I had a local saved copy of my Shopify theme files that I assumed was current. On September 11th, checking the real live theme directly showed it wasn't even close: the live version had a completely different file structure for its FAQ section than my saved copy did. The lesson wasn't "back up more often." It was that a saved copy, no matter how recent it looks, should never be trusted over pulling the real live file first, every single time, before touching anything.
Assuming something still needed to be built when it already existed
During a full SEO audit on September 16th, structured data markup for blog posts and FAQ sections looked like real, unbuilt work, based on an earlier read of a local, outdated copy of the theme. Checking the actual live theme file directly showed both were already complete and already live, hand-built directly into the theme months earlier. The work I thought I still owed the site had already been done. I just hadn't checked the real, live file closely enough to know it.
What almost went wrong during the big folder reorganization
While moving three years of scattered files into one folder per brand, one folder had its own separate hidden version-tracking files that didn't move along with everything else in a plain file move. It briefly ended up staged as a broken, disconnected reference pointing at nothing, the kind of thing that's easy to miss until it's already committed. It got caught by checking exactly what was staged before committing anything, not after, which is the only reason it didn't turn into a real problem.
The pattern underneath all four
Every one of these looked like it should take five minutes: nudge a score, edit a file, check a schema, move a folder. Every one of them only revealed the real story once I actually tested it for real, instead of trusting how simple it looked on the surface, in either direction. Two of them turned out to be harder than expected, and one turned out to be easier, and I couldn't have guessed which was which just by looking at the task on paper.
What that changed about how I work now
I check live sources directly instead of trusting a saved copy, I run a status check before and after anything that touches a lot of files at once, and I've made peace with the fact that a metric can be genuinely fine for real visitors even when a testing tool insists otherwise.
If you want the fuller story of why I keep building things myself instead of hiring it out, why I started Marie Glow Studio is the longer version.