I Used Claude To Rebuild a Website Without a Developer, and It Worked: Part 1
Liz is my wife and a professional photographer, and her website had quietly decayed for years the way small business websites usually do when no external site manager looks after them.
For 25 years, I've successfully run and scaled media properties, but in all that time I've never written a single line of code. Did that stop me from tackling a full-on revamp of her site? Absolutely not! Now, lizlabiancaphotography.com has 11 purpose-built pages, four categorized galleries, forms that actually go somewhere, and a homepage that is clean, smooth, and indicative of the true professionalism of her images.
I wanted to dive into solving and fixing something that was failing her business myself, and it worked. Here's how I did it.
[Click on image for larger view.]
Before my Claude-assisted site revamp.
(Source: lizlabiancaphotography.com/Wayback Machine)
|
[Click on image for larger view.]
The after. (Source: lizlabiancaphotography.com)
|
3 Broken Details Hidden in Plain Sight
Before I touched a single setting, three broken details told the whole story:
- The contact widget was quietly forwarding incoming leads to [email protected], an address belonging to an employee who had moved on over 10 years earlier.
- The Instagram link in the footer pointed directly to a dead handle that served an error page to every visitor who clicked it.
- To make matters worse, the pricing page was password-protected, hiding her rates from anyone trying to book her.
In short, the site wasn't broken enough to trigger an emergency rebuild, but it was certainly not working well, either.
I run a media company, so I understood high-level web concepts from sitting in rooms with our front and backend developers. Still, I had never personally run a Pagespeed performance audit until I sat down to work on this site. I was completely ready to do the reading and learn the mechanics on the fly, with my foundation built on executive experience rather than hands-on coding. I knew to ask for a hero image that was optimized for phone screens and to verify that images were compressed before going live.
Surprisingly, none of those suggestions came from Claude, which answered what I asked but never once suggested to me what to ask for. Someone without that prior background gets a site that looks fine on a laptop and ships with bloated files that can easily break on mobile screens.
What Happened Quickly (and What Didn't)
The new layout and core pages came together during the first 12-hour session of me working on this. I established the basic typography and page structures much faster than I had anticipated. But design and refinement ended up spanning six full sessions, spread across weeks. I was hunting down mismatched fonts and fixing contrast problems across the site before re-art-directing the portfolio grid.
Looking back across the entire timeline, my rough estimate places the overall effort at 20 percent building and 80 percent verifying. Most of my calendar time was spent proving whether a fix actually worked or merely created a new complication.
Another hurdle that ate up more time than I expected: Early in the process, I made a layout change, verified it on my laptop and opened the site on my phone...only to see the old version. Six separate checks insisted the cache was clear, but my phone stubbornly served three different stale copies across Safari and Chrome. I spent an entire hour convinced it was my phone or my Wi-Fi. I toggled between 5G and home broadband, opened private tabs and cleared my browser data twice, entirely sure my own device was at fault.
Then Claude worked out what was happening: the server was storing a separate copy of the page for every kind of browser that requested it. Clearing the cache from my laptop cleared exactly one of those server-side copies, leaving every mobile view untouched.
The only way to have known this was an issue required me to physically test the site on my actual phone and iPad. I was no longer debugging just the website at that point, but debugging my own testing instruments as well.
Realizing the Plumbing Was Already Condemned
By every customer measure, that initial pass made the site significantly better than where it started. The galleries loaded cleanly across devices and the layout held up. Then I hit a hard ceiling when I realized the theme had no remaining upgrade path and the underlying server language went out of support years ago.
All that early troubleshooting amounted to redecorating a building that was already condemned.
In Part 2 next, the view from 50 hours later.
Posted by Daniel LaBianca on 08/24/2026