I Rebuilt a Website With Claude, Part 3: What I Wish I Knew From the Start
I've spent two blog posts now sharing the long, arduous and imperfect process I undertook to rebuild my wife Liz's photography website using Claude (you can refresh your memory here and here). In this installment, I'll go over what I would actually say to another executive who's about to hand a real project to Claude or any other model. None of it is specific to websites.
Claude answers what you ask; it won't tell you what to ask. I made this point in Part 1 and I am making it again because everything else on this list is a version of it. The prompts that saved this project focused on things like how images load on a phone and whether files were compressed before they went live -- things that occurred to me to ask because of the 25 years I've spent sitting near this work.
Claude answered every one of them well and volunteered none of them, and nothing in the conversation flags what you failed to ask.
Check the foundation before you optimize anything on top of it. Ask the AI early and specifically whether what you are building on is still supported. I spent a weekend making a platform faster that turned out to have no upgrade path left. Progress at the wrong layer feels exactly like progress until it doesn't, and nothing in the tooling will tell you which layer you are standing on.
Work inside a project. This is the most practical thing I learned and nobody told me going in: Context does not travel between conversations, so every new chat starts from zero, which I found out when I hit a weekly usage limit and lost three days of forward momentum.
A project holds the files. Every document the model produces gets saved where the next session can actually read it, and you can attach a new chat or a working session to that same project and it picks up where you left off.
Then keep asking for the handoff document. I only asked for a handoff document when I got stuck. In fact, I should have been asking at the end of every session whether I needed it or not, because the record was only ever as current as the last time somebody requested it. The gaps between those requests are exactly where the repeated mistakes lived.
Most of the work is verification. As I mentioned in Part 1 (and still find hard to believe), my time was roughly split between 20 percent building and 80 percent proving the build had actually worked. That ratio held throughout the entire project.
Whatever you think a project like this will take, just know that making is the fast part, and establishing that the thing you just made did what it claimed is where your calendar goes.
Some checks require a person. The check that finally explained a week of confusion that I described in Part 1 could not be run by any tool I had. It took me standing in my kitchen with a phone in one hand and an iPad in the other. Plan for that step from the start, and put someone on it who will actually go and look.
Your open questions are the bottleneck. Every real delay on this project traced back to a decision I hadn't made yet. Building was fast. The more expensive hours went to judgment calls, and the calls that I got wrong, I got wrong in the first two days. If something like this is running long, look at your own undecided list before you look at the tool.
Where This Stops Being Worth It
This project revolved around a small-business website with one stakeholder who happens to be married to me. Whatever you're responsible for is likely bigger and connects to systems I never had to think about. The failure modes I ran into all get worse with scale.
None of this is a knock on the tools I used. They are genuinely good, and Liz has a much better website because of them. But hand those tools to somebody who does this for a living, and they'll go further and faster, skipping most of the mistakes I made because they would have seen them coming.
That is the part to sit with if you are considering doing something like this inside your own company. The 50 hours I spent redoing Liz's website with Claude were free because they were mine and they came out of weekends. Your own hours are not free. Every hour you spend learning something a developer already knows is an hour you did not spend on the work only you can do, and that is the work that actually makes the company money.
So the recommendation is narrow. Do this once, deliberately, on something that matters to you but does not matter to your company. You will learn more about how these tools actually fail in one weekend than a year of vendor briefings will teach you. Then hire the developer and hand them the same tools.
Because the thing I understand now that I didn't understand when I first started this is that a developer isn't the person who types the code. A developer is the person who would have known what to ask.
Posted by Daniel LaBianca on 09/15/2026