This site's homepage used to open with a headline and a terminal-style animation. I replaced it with a deck of cards — a real, working, responsive grid of image tiles that click through to actual destinations: apps, projects, and accounts, not placeholders. Getting there took a lot of small iteration first: a 28-card layout that felt too heavy became 21, four color themes narrowed to one, and a plain click became a proper detail view — a modal with a single close action and its own open/click tracking, so a card that gets clicked and a card that leads somewhere are measured separately.
One rule shaped most of the small decisions: a border on a card means it goes somewhere. Cards without a real destination don't get the hover lift, the glow, or the frame. It sounds minor, but it's the difference between a deck that looks finished and one that's actually honest about what's clickable.
The site that wouldn't update
The harder problem showed up after the design work was done. I pushed the changes — repeatedly — and the live site kept serving the old version. Not stale by a few minutes; it simply wasn't picking up any of the new commits, push after push.
The instinct is to blame caching, and I checked that first. It wasn't the cache. The actual cause was a routing rule that had been pinned, at some earlier point, directly to one specific old build's URL — bypassing the normal "serve whatever's in production" path entirely. New deployments were succeeding; they just weren't the thing routing traffic. Once the routing rule was pointed back at production and the site redeployed, the live version matched the local one exactly, byte for byte.
The lesson worth keeping: if a static site stops reflecting pushes and the response headers say the request isn't even hitting a cache, stop debugging the cache. Check what's actually deciding which build gets served — that layer can get stuck in a way that looks identical to a caching problem from the outside.