I had 40 screenshots saved in a folder. Three false starts. And a personal site that had been bothering me for years.

The site wasn’t bad. It worked. But it was a mishmash. I’d been an occasional blogger, but I’d also done a lot of speaking and was interviewed fairly often. I had different projects I wanted to showcase, clients I’d worked with, and things I’d built. The site tried to do all of that, and the result was a general representation of me, with no rhyme or reason to its structure. This blog started 20 years ago and evolved through different phases: things I was into, then I’d get busy and stop, then new interests, then busy again. The content reflected all of that.

I knew I wanted to focus on how I’m using AI, documenting the process, sharing what I’ve learned, writing about workshops and projects. But every time I tried to redesign the site to match that direction, I’d fall into the same pattern. I’d start looking at other sites for inspiration. I’d screenshot something I liked. Then another. Then another. Pretty soon, I had a hundred screenshots and no idea how to turn them into a coherent design. It was paralyzing.

The thing is, this only happens when I’m designing for myself. With clients, I never have this problem. They hand me a style guide, sites they admire, and a sense of what they want structurally. That’s the blueprint I need, and I can hand it to my team and go. When it’s my own project, there’s no brief. There’s no client to give me the constraints. Just me and a growing folder of screenshots.

I’d already used Claude Cowork for content strategy and Claude Code to build Bassists.com from scratch. I knew I could go into this project with a mix of clear direction and open questions, steer the tools where I was solid, and collaborate where I needed pushback. Claude Design had just launched, and I wanted to see if it could break the one part of the process that had always stalled me. That’s what finally got me moving.

Starting with the content, not the design

A lot of people start a site redesign with the visual. I’ve always believed you start with the content. You don’t bring in the interior designers before the architect. What kinds of pages am I going to have? What’s the content on those pages? What’s the structure? Once I know that, then I can think about how it should look. Not the other way around.

That’s why the first tool I used was Claude Cowork. Before I touched anything visual, I needed to figure out what was staying and what was going.

I exported the existing site and gave it to Claude Cowork. I described my vision for the new site, acknowledged that there was a lot of junk on the old one, and we went through everything with a keep, kill, or refresh approach. Which posts were worth keeping? Which ones were getting Google traffic? Which ones were milestones worth preserving? And which ones were just noise?

Claude Cowork was impressive. It put on the cap of someone who understood taxonomy, content strategy, and consistency. It flagged things I had to explain (“No, that one stays, and here’s why”), but that’s exactly the kind of pushback I want. I tell every LLM I use: be my sparring partner, not a rubber stamp.

The speaking posts were a good example. I’d done a lot of speaking over the years, and in my mind, those posts were part of my history. Claude Cowork flagged them as noise. My initial reaction was emotional: I was proud of those engagements. But when I thought about it in practical terms, most of those posts were thin. A sentence or two and an embedded video. No depth on what I actually talked about. A site visitor scrolling through a list of “I spoke here” pages gets nothing from that. Claude Cowork was right. They needed to go.

And then it got something spectacularly wrong. It suggested removing a post about bass because I wasn’t an authority on the topic. I founded No Treble, the leading online magazine for bass players, ran it for 16 years, and had just built Bassists.com. That’s AI not knowing what it doesn’t know, and it’s exactly why the expert has to be in the loop.

As we worked through each section, I used Wispr Flow to dictate running notes into Claude Cowork. Every time a decision created a downstream task, like a 301 redirect or a schema update, Claude Cowork appended it to a project plan I could reference later. That kept me from losing track of the technical implications while I was focused on the strategic decisions.

Even when I felt solid about where we’d landed, I took the work to Gemini for a second set of eyes. That’s a step I routinely take with any significant AI output, and it’s something I teach in my workshops: don’t rely on a single model. Gemini pushed back on a few things. Some of it was off base, but some of it was relevant. When that happened, I’d filter the feedback, restate the points that had merit in my own framing, and bring them back to Claude Cowork for another round of sparring. The content architecture that came out of this phase was the foundation that made everything after it, the design, the build, the content, come together much more easily.

Designing for everyone but yourself

I’ve designed many websites. I’ve led design and development for projects from small to enterprise. I tackle it head-on and don’t have any qualms about it. But when I’m designing something for myself, it’s excruciatingly difficult.

Claude Cowork actually called this out before I moved to Claude Design. It correlated my screenshot-hoarding habit with ADHD: the tendency to keep collecting, keep looking, and get overwhelmed before ever making a decision. It was right, and just having it named helped me approach Claude Design differently. I didn’t bring 100 screenshots. I brought the kind of brief I’d normally get from a client: a color scheme, screenshots of my current site with specific notes on what I didn’t want, a set of Google Fonts I wanted to explore (more than I’d ever use on a site, but I wanted to see pairings), and a description of the feel I was after. Not blocky. More open, more breathing room. A site built around reading. That sensibility goes back to my graphic design days doing typography for books: readability, space, letting the content sit comfortably on the page.

I’ll be honest: Claude Design was the tool with the most friction. The first iteration went in a direction I hadn’t asked for. Radical colors that weren’t part of my palette. It changed the words I’d given it, which matters more than people realize. A three-word blurb that looks great in a design comp falls apart when real content needs six or eight words. I’ve seen that happen on enough projects to know you need to design with realistic content, not placeholder copy that flatters the layout.

It also had a habit of describing its rationale in fluffy design terminology I couldn’t parse, even with my background. I tried to get it to explain, gave up, and just said, “Do it.” That didn’t help either.

Over several iterations, we got closer. I repositioned away from the magazine concept I’d initially explored and focused on what the site actually needed: a clean reading experience with structured content. At each step, I had Claude Design update the design system file for colors, typography, spacing, and component patterns. One of the first things Claude Design asks is whether you have a design system to upload. I didn’t have one going in, so we built it as we went. That turned out to be the most valuable outcome of the Design phase. By the time I was approaching the token limit, I had a solid design system and core templates. Not every page was designed, but the building blocks were all defined in one place, and that’s what made everything after it possible.

Building the site with Claude Code

Rather than wait days for Claude Design tokens to replenish, I made a judgment call. I had enough in the design system to guide Claude Code through the remaining templates. If it didn’t work, I could always bring screenshots back to Claude Design later.

The first thing I had Claude Code do was audit what Claude Design had produced. I found CSS scattered across individual template files instead of being consolidated in a single stylesheet. Performance, consistency, and maintainability all suffer when styles are fragmented. I had Claude Code refactor everything into a clean structure, putting the results in a separate folder so I could do side-by-side comparisons with the originals. It worked well.

From there, I scoped the WordPress build. This was simpler than Bassists.com, which had custom post types, complex taxonomy relationships, and API integrations. This site is largely WordPress out of the box. I outlined the custom elements, the blocks I wanted, the taxonomy tie-ins for content coming post-launch, and highlighted where things appeared in the templates. I didn’t need to explain what a post or a category is. I needed to explain what made this site’s implementation specific.

Then I followed the same process I use on every project with Claude Code. I asked for its understanding of what we were building. I refined whatever was off. I asked for the task list in the order it recommended. We fine-tuned that, and then I said, “Let’s tackle the first task.” I had a local WordPress environment set up, so each time it finished a step, I could hit refresh, see the result, review the code, and give it feedback.

One thing that surprised me was how useful screenshots became as a collaboration tool. I’d screenshot a section of the site and say, “This feels crowded right here.” Because I’ve told Claude Code to push back on me, sometimes it would disagree and explain why the spacing worked. I’d look again and think, “You’re right.” Other times I’d say, “No, try this instead,” and it would. It felt like working with a teammate.

The best moment was when I screenshotted an entire page for review, and Claude Code said, “You pasted this section twice.” It caught a duplicated heading and paragraph from a screen grab. I would have found it eventually, but who knows how long it would have been live on the site.

While Claude Code built the theme, I was back in Claude Cowork developing the content. I had transcriptions of talks and interviews that needed to become real posts. I’d identify the key points I thought were important, give those to Claude Cowork along with the transcription, and ask it to pull out what I actually said around those topics. I’d also ask what it found interesting that I might have missed. That helped me turn thin posts into substantive articles (like this one) without just dumping a transcript on the page.

Why this site exists

I’ve spent years telling clients and audiences to own their platform. Don’t build your entire presence on someone else’s property. If it goes away, you’re gone.

I wasn’t following my own advice. I was writing on LinkedIn and letting it disappear into the feed. A post from a year ago is nearly impossible to find. I don’t own the taxonomy. I’m sharing hashtags with everyone else. It’s difficult to point somebody to something and say, “I wrote about this.”

Here, I can. I can write longer form. I can organize content by topic. I can link related posts. When someone asks, “What are you doing with AI?” or “How do I think about this?”, I can point them to a tag on this site and say, “Here are three articles on that.”

I’m the biggest taxonomy nerd I know. It’s what I’ve built for clients and big projects for decades. I just wasn’t doing it for myself. The cobbler’s kids had no shoes.

The reason I finally tackled it is because I knew Claude would help. Claude Cowork for the strategy and content. Claude Design for the visuals. Claude Code for the build. Each tool did a different job, and I managed the project the same way I’ve managed web projects for 30 years: with clear scope, step-by-step execution, and my hands on every decision.

If you want to see what I’m writing about AI, start with the Working with AI posts. More is coming.