Building This Site with Claude Code

This one is more of an editorial decision than a coding session, but it belongs in this log for the same reason everything else does: it's a real thing I changed about how this project works, and I want to be upfront about it. A few weeks back, I rewrote every entry already in this Build Log into plainer language, and swapped out language across the site that mainly spoke to "AI engineers" for wording that welcomes anyone who uses AI, not just people who write code for a living. That was step one.

Step two is happening now, and it's about the blog itself, not just this log. Looking back at recent posts, some had wandered into heavier, more abstract territory: bigger ideas about AI, deeper dives into how the underlying technology works, that kind of thing. Interesting to write, and there's a place for it, but it's not the daily bread this community was built around. I'm pulling the default back toward everyday, practical value: a tip you can use today, a tool worth trying, a habit worth building, a mistake worth avoiding.

The reason I keep coming back to plain, practical writing is the audience I actually have. This site is meant to work for three different people at once: someone who's never touched an AI tool, an experienced engineer who builds with them daily, and someone who's just curious what the fuss is about. A concrete tip serves all three. A deep theoretical detour mostly serves one. So theory isn't gone, it's just seasoning now instead of the main course. The occasional deeper post is still worth writing when there's a genuinely useful idea behind it, it just shouldn't be the default shape of a post.

Tooling note: this session ran on Claude Sonnet 5, going through the existing Build Log entries and the site's framing copy together, then talking through where the blog's center of gravity should sit going forward.

Tooling note: this session used Claude Opus 4.8, a high-effort AI model well suited to this kind of detail work.

One of the blog's topic tags ("Misconceptions and Myths") was supposed to show up orange, but on the live site it had no color at all. Here's what happened: when a website gets prepared for publishing, a tool scans through the code and throws out any styling it can't find being used, to keep the site fast and lightweight. That tag's color was defined in a file the tool wasn't checking, so it assumed nobody needed that color and deleted it. Every other tag survived by luck, because their colors happened to also show up somewhere the tool was checking. Once I told the tool to check that file too, the orange came back, and the fix protects every tag from the same mistake, not just this one.

I also moved the last two posts that were still hardcoded into the site's code over to the database, so the entire blog now lives in one place and can be managed from the admin panel instead of requiring a code change. The public blog pages were already reading from the database, so the real work was deleting the old hardcoded copies and updating the couple of spots, like the sitemap (the list that helps search engines find every page on the site) and the "related posts" feature, that were still looking in the old location.

Editing a post and saving it a second time was quietly creating a duplicate. After the first save, the editor didn't realize the post already existed, so a second save, like clicking Save Draft and then Publish, created a brand new copy instead of updating the original. Now the editor remembers which post it just saved, so a second save updates it instead of duplicating it.

Last, I tested the whole draft-to-published process from start to finish, confirming that drafts really do stay hidden from visitors, both in what the site displays and in the underlying permission rules that back it up. I added a preview button so I can see exactly how a post will look before it goes live, and set the publish date to fill in automatically on the day a post actually goes public.

Tooling note, as always: this session used Claude Opus 4.8. Speed problems are a good match for a slower, more careful AI model, because the real fix is rarely the first thing you'd guess.

Before touching any code, we measured. When you prepare a website to go live, there's a report showing exactly how much data each page has to send to a visitor's device. That report told the story before we changed a single line: pages that talk to the database were sending roughly two and a half times more code than the one page that doesn't, and the home page was redoing all its work for every single visitor while showing nothing on screen until that work finished.

The first problem was that the slow work was happening in the wrong place, in the visitor's browser instead of on my server. The home page would send an empty page first, and only then would the visitor's browser download a large toolkit for talking to the database, connect to it, and ask three separate questions, two of which meant reading through every single story. That's about the slowest way a page can load. The fix was to do that work on the server, once, before the page is even sent out. Now the very first thing a visitor receives already has the stories and stats built in. Three questions to the database became one, and the loading spinner is simply gone, because there's nothing left to wait for.

The second problem, the endless force-refreshing, was something else entirely. When I approve a story or publish a post from the admin panel, that change goes straight to the database. But the site also keeps a saved copy of each page, called a cache, to make it load faster for visitors, and nothing was telling that saved copy it was now out of date. So the site kept showing the old version for a few minutes, and refreshing my browser didn't help, because the outdated copy lived on the server, not on my computer. The fix: every time I make a change in the admin panel, it now automatically tells the site "that page changed, throw out your saved copy." Changes show up immediately now.

Here's the part that matters most, because it's really about testing, not speed. I didn't just assume it worked. I ran the real, ready-to-publish version of the site on my own computer and checked exactly what it sent out: confirmed the story text showed up in the very first response instead of arriving late, confirmed the page was now allowed to be saved as a cached copy, and then tried to trick the new "clear the cache" feature from the outside, once with no password and once with a fake one, to make sure it correctly refused both times. A fix that looks right in the code isn't the same as one you've actually watched work.

This is the same approach I use for every feature, just pointed at speed instead of a new feature. I can't read a code change and know in my gut that it saved a second of load time. But I can measure the site before and after and watch the numbers move, and I can open the real site and watch content appear sooner. Describe the result you want, then go check that you actually got it. Don't just trust that the code looks right.

A note on which AI model I'm using, since people ask: Claude's newest model, Fable 5, is still in limited release, so like recent sessions, this one ran on Claude Opus 4.8, this time set to its highest effort level, which I've been leaning on for trickier debugging. The good news: a single top-tier AI model at high effort has stayed comfortably within my usage limits at this project's pace. I haven't had to ration it to get real work done, which is reassuring before inviting more people in.

The first bug, and the most important one: a real visitor tried to submit their story and got a generic error message. It worked every single time when I tested it myself, which was the giveaway. When you leave an optional field blank, the form quietly treats it as "nothing entered," and the database's own saving tool throws an error the instant it sees that value, on the very first optional field on the form. I had simply filled in every field every time I tested it. The fix: tell the database to just skip empty fields instead of choking on them, and stop the form from hiding the error, so the next failure will actually be visible to me.

The second bug: a tester who lives in Bowie, Maryland showed up on our world map as a dot in Texas. The submission form only asked for city and country, and it turns out there's a "Bowie" in more than one U.S. state, so the location lookup tool confidently guessed the wrong one. There's no clever trick that fixes a mistake like this, the real fix is asking for more information. So I added an optional state field, which turns the lookup into "city, state, country" instead of just "city, country," and I built an admin tool to fix any pin after the fact, either by looking it up again with better information or typing in the exact coordinates myself. Automatic location lookup will never be perfect, and I already review every story anyway, so a ten-second manual fix beats chasing an accuracy I can't actually promise.

The third bug arrived wrapped inside a new feature. I had just improved the comments section so commenters can add a LinkedIn link, and so I can view and delete any comment from the admin panel. While testing that, a comment saved correctly and showed up in the admin panel, but not on the public story page. The public page asks the database a very specific question: "show this story's approved comments, newest first." A question shaped like that needs the database to have a shortcut set up ahead of time (developers call it an index) so it can answer quickly, and that shortcut had never been created. The question was failing, and the failure wasn't showing up anywhere, so the page just looked empty with no explanation. Creating that shortcut fixed it instantly, and again, I made sure future failures like this won't hide silently.

The thread connecting all three bugs is really the whole point of this project. In my own testing, I fill in every field, type a city I know is unambiguous, and post one comment. Real people leave fields blank, live in towns that share a name with other towns, and do things in an order I never planned for. As more people use the site, that pattern only gets stronger. Every new visitor is, for free, testing the site in ways I never would have thought to. Growing a project built this way turns out to be less about writing more code and more about listening closely for what breaks and fixing it fast.

A quick note before the details: Claude's Fable 5 model wasn't available today, so this session ran on Claude Opus 4.8 set to high effort. Same process, different engine under the hood.

First problem: a cover image linked from Google Drive wouldn't show up. My first instinct was to blame the file itself, but the image was never the issue. A Google Drive "share" link points to a webpage that lets you view the image, not to the image file itself, so the browser was getting a whole webpage back instead of a picture. On top of that, the site only trusts images from sources I've specifically approved, as a security precaution. The simple fix was to stop fighting both problems: I put the image directly in the project's own files, so our own website serves it as a real, shareable image link. No outside service needed.

Second problem: the home page wasn't showing posts written through the admin tool. The home page was only reading blog posts that were hardcoded directly into the site's files, while posts made in the admin panel live in the database. The main blog listing page already combined both sources correctly; the home page had just never gotten that same update. I fixed the home page to combine them the same way, so the newest post now shows up everywhere it should.

Third problem, and the most interesting one: a freshly published post said "Page not found," even though it clearly existed and showed up fine on the blog listing page. The cause was a mismatch in the site's permission rules, the rules that decide who's allowed to read what from the database. Those rules only allow a certain kind of question, one that's guaranteed to return only published posts. The blog listing page asks that allowed kind of question; the individual post page was instead asking a different, disallowed kind of question. The database was correctly saying no, but the website was mistakenly turning that no into a generic "page not found" instead of explaining what actually happened. Rewriting that one page's question to match the allowed pattern fixed it.

Fourth problem: sharing a post to LinkedIn showed the site's generic logo and title instead of that post's own image and headline. Here's why: when you share a link, LinkedIn reads special information baked into the page's code ahead of time, it can't run the page's interactive features, it only sees what was already there when it arrived. Posts from the admin panel were only being loaded after the page reached a visitor's browser, so there was nothing post-specific for LinkedIn to read yet. I changed the page to load that post's information earlier, on the server, before sending it out. LinkedIn's own preview checker confirmed the fix worked.

Last problem, and the one I most wanted to rule out as serious: a post dated June 14th was displaying as June 13th. That's exactly the kind of thing that makes you worry the date got saved wrong in the database. It hadn't. The date was stored correctly. The bug was in how it got displayed: the display code read the plain date as if it were midnight in a global reference time zone, then converted that moment into my local U.S. time zone for display, which rolled it back to the previous day. Telling the display code to just show the date as-is, without converting time zones, fixed it. Nothing needed to be repaired in the actual data.

I gave Fable 5 one paragraph describing what I wanted: a new page where people could follow along with how I use Claude Code, Anthropic's AI coding tool, to build this site. No wireframe, no spec, no list of features. It read through the existing site's code, matched the visual style of the blog page, created a file to store these entries so future ones are easy to add, added the new page to the site's navigation menu and search-engine listing, and wrote the first draft of these very entries by reading the project's own history of code changes.

That last part is what struck me. I never told it what happened on May 18th or May 31st. It pieced together the story of this project from the log of every code change I'd made, a record that Claude Code itself had written over the past month. The project had started documenting itself.

As AI models get more capable, my job shifts further toward reading and judging the result instead of building it myself. I read this page the same way you're reading it now: checked the dates against what I remembered, and asked for changes wherever the tone felt off. I didn't review the code itself. I reviewed the finished product.

Up to this point, the admin page had no login at all, which was fine while the site was just a prototype on my laptop, but a real problem the moment it went public. I asked Claude Code to handle the whole pre-launch checklist in one sitting: lock the admin page so only I can get in, remove the fake sample stories and placeholder text, add the ability for visitors to react to and share stories, and give me a real admin experience.

The part I couldn't have built quickly on my own was the blog editor. I described what I wanted in plain terms: "I want to write and publish posts without redeploying the whole website." Claude Code built an editor connected to the database that combines its posts with the older, hardcoded ones on the public blog page. When the subscriber list tab didn't show up where it should have, I just described what I was seeing, and it found and fixed the problem.

My way of checking all of this was to just try using it the way a visitor, or an intruder, would: log in, log out, try to reach the admin page without logging in, publish a draft, unpublish it, check that the public page updated. I never opened the code that handles the login itself. I tested whether the door was actually locked instead of reading the blueprint for the lock.

This was the first time the project faced a real security warning instead of a hypothetical one. A public security advisory (these get an official ID called a CVE, short for Common Vulnerabilities and Exposures) came out for React Server Components, which is the exact underlying technology this site is built on. Instead of spending my evening reading the technical advisory and comparing it line by line against my own code, I brought it to Claude Code and asked two plain questions: are we actually affected, and what's the safest, smallest fix?

It walked me through which parts of the warning applied to our setup, updated the affected pieces of code, and we shipped the fix as a proper, reviewed change that I approved after checking a preview version of the updated site. The whole process felt less like patching software myself and more like consulting a security expert who could also do the work.

For someone building this mostly solo, that matters a lot. Responding properly to security warnings is exactly the kind of work that gets skipped on side projects, because it's urgent, unfamiliar, and thankless. Making it cheaper to do right means it actually gets done.

Day two was less about big structural decisions and more about the hundred small things that separate a rough draft from a real website. Claude Code built the entire search-engine and social-sharing setup in one shot: page descriptions, a sitemap (the list that helps search engines find every page on the site), a file of instructions for search engines, and the images that show up when a link gets shared on social media. Each change took me a sentence to ask for and a minute to check.

The email work was the more instructive part. Email is notoriously difficult to get right, and the newsletter's logo and unsubscribe link rendered wrong in real inboxes in ways no amount of reading the code would have caught. My process was: send myself a test email, take a screenshot of what looked wrong, describe it in plain words, and let Claude Code adjust the email template. After three or four rounds of that, the emails looked clean everywhere.

This is the clearest version of the process I keep coming back to: I can't judge whether email code is correct just by reading it, and I don't need to. The inbox itself is the real test.

This is the session where Claude Code stopped feeling like something that just writes code and started feeling like a full technical teammate. Building the every-two-weeks newsletter pipeline meant connecting to Google Cloud for the Gemini AI model, Gmail for sending the emails, Vercel (the service that hosts this site) for deployment settings, and a separate service for storing the subscriber list. Each one of those has its own command-line tool, its own login process, and its own way of naming things.

The real debugging story from that day: new subscriber signups were silently failing to save, but only on the live site, not when I tested it locally. Claude Code traced the problem through several layers that would have taken me hours to work through alone. The setting names that Vercel automatically creates for its database connection didn't match the names the code was expecting, and on top of that, the code that saved a new subscriber needed to run on the server instead of directly in the visitor's browser, for security reasons. Two small fixes, and it was solved.

It also handled a version change for me. We started building on one version of the Gemini AI model, and when a newer one came out, switching to it was a one-line conversation. The rest of the pipeline never had to change.

A community site that accepts public submissions is basically an open database with a friendly front door, if you get the permission rules wrong. So the second work session of day one was a security review of the first. I asked Claude Code directly: if you were trying to break into what you just built, how would you do it?

The answers were specific and useful. First, an example configuration file containing hints about the site's setup got removed from the project entirely, since that kind of file shouldn't be public. Then the database's permission rules were tightened: anyone can submit a story, but only approved stories can be read by the public, and only I can approve or edit them. The genuinely educational part came next: those tighter rules were initially too strict, and they accidentally blocked normal, legitimate use of the site too. Watching Claude Code sort out the difference between "can this specific piece of data be read" and "can this general kind of question be asked at all" taught me more about how database permissions actually work than any article I've read on the subject.

I checked the result the way someone trying to break in would: tried to read unapproved stories directly from the browser's developer tools, tried to write to parts of the database I shouldn't be able to touch. The rules held both times.

This project started as a description, not a blueprint. I told Claude Code what the site was for: a place where real people could share real stories about using AI, with a world map showing where those stories come from, alongside a regular blog. From that description alone, it built the entire foundation: the website framework, the styling system, a database to store everything, and the mapping tool behind the interactive map.

The record of code changes from that first day reads like a time-lapse: the initial build, newsletter setup, the story feed, map pins, location lookup, individual story pages. Eighteen separate changes in one day. Each one started as a short conversation: I described what I wanted, or what looked wrong, Claude Code made the change, and I checked the live result.

Here's the part I want to be upfront about, because it's the whole reason this Build Log exists: I didn't read most of this code. I've built software before, but my role on this project is deliberately different. I check the results, not the code itself. I click through the site, try to break the forms, check that the right data lands in the database, and judge what I see. This whole project is quietly testing whether that's actually enough to build and run something real. So far, the answer has been yes, with one honest caveat: knowing what to check for is its own kind of expertise.