What I Ship in a Week With Claude Code: A Build Log

Most writing about building with AI agents is either a demo or a manifesto. This is neither. It’s a log of one working week, on one real project, with the pull request numbers.

The project is this website. In the first week of September I repositioned it from “a directory with a studio attached” to “a studio with a directory attached,” which touched nearly every page, the data behind them, the build, and the legal pages. I picked this week because it’s concrete: the spec and the commits exist, the pull requests have numbers, and the result is the site you’re reading.

Here’s what happened, day by day.

Wednesday: decide before building

The week started with no code. It started with a document.

I wrote a spec with a decision table: what the studio is and isn’t, which brand leads, whether the Foundry has members yet (no), whether it has a paid tier (no), whether the “Deploy” product in the nav was live (no), whether the Stockyard’s “reviews” were hands-on reviews (no), whether any affiliate links existed (none), and which open-source license the platform tools carry (Apache-2.0). Fourteen rows. Each one a claim the site was making or was about to make, with a yes or no next to it.

That table did more for the week than any prompt. Every “no” became something to remove. Every “yes” became something the agent could build against without asking. And the whole thing became the input to the content guard I’ll get to below, because a decision you’ve written down is a decision a script can enforce.

Anthropic’s guidance for Claude Code puts it as “explore first, then plan, then code,” and warns that skipping the plan “can produce code that solves the wrong problem.” I’d put it more bluntly: an agent will build whatever you ask for, quickly and well, so the expensive mistakes are all in the asking.

One more thing I found on Wednesday: the main branch hadn’t deployed since a dependency upgrade in March. The live site was running an older build. First engineering job of the week, before any of the exciting work: make the build work again.

Thursday: build and ship the repositioning

Thursday was the big day. Ten commits, one pull request (#7), about 4,800 lines added and 4,400 removed, merged that evening.

In order:

1. Toolchain. Pin Node 22, add a type check to the build, fix a blog schema error that had been silently breaking things. This was the March problem, fixed forward rather than rolled back.
2. Layout foundation. One base layout for every page, page titles composed from data, branded share images generated by a script, and a content guard: a script that scans every built page for strings that must never appear and fails the build if it finds one. The forbidden list came straight from Wednesday’s table.
3. Ventures as data. A /ventures page driven by a single data file, with redirects from the old portfolio paths, and the platform tools rendered from data rather than hand-written HTML.
4. Navigation as data. Header and footer built from one nav definition. The “Deploy” item, which pointed at a product that wasn’t live, removed.
5. Home. A studio-first hero, a founder block, and a strip showing the ventures.
6. Stockyard honesty. A methodology page explaining where the 865 listings come from, “Verified” relabeled to mean “official or production-grade source” rather than “tested by us,” and search scoped to listings.
7. Copy. About, Foundry, Learn, Platform, Philosophy, Contact rewritten to the decisions.
8. Legal. Terms of use and a privacy policy, drafted for counsel review.
9. Blog alignment. The five posts lightly edited for the studio identity.
10. Docs. The spec recorded with its resolutions, the project’s CLAUDE.md refreshed, and the sub-brand links whose domains didn’t resolve parked with dated notes rather than shipped as dead links.

What Claude Code did, and what I did

The honest split, for anyone trying to picture it:

Claude Code did the reading, the refactoring, the data modeling, the component work, the redirect plumbing, the share-image script, the guard script, the first drafts of every page’s copy, the legal page drafts, and the fixes when the checks failed. It ran the build-and-verify loop itself and came back with results rather than guesses.

I did the decision table, the review of every diff, the wording of every claim about what the studio is, the choice of what to remove, and the final read of every page. I rejected a paid-membership pitch for the Foundry that read well and wasn’t true. I rejected “reviewed and tested” language for the Stockyard for the same reason. I rejected a slide for a product that didn’t exist. None of those were the agent’s fault. They were plausible. Plausible is exactly the failure mode a human is for.

How I knew it was safe to merge

One command runs the type check, the full build, the search index, and the content guard. If any of it fails, the command fails. A second command checks every venture link and reports which domains resolve.

The agent ran these until they passed. Then I read the pull request. Then it merged, and the site deployed itself within minutes.

That’s the loop. The agent does the doing and the checking. The checks decide whether it’s done. I decide whether it ships. From the “Give Claude a way to verify its work” section of the Claude Code guidance: “If you can’t verify it, don’t ship it.” The whole week was built around making that sentence cheap to obey.

Friday: three small follow-ups

With the foundation in place, Friday’s changes were small and fast, which is the point of a foundation.

• #8: a new venture, live sub-brands for another, a “Live” badge in the status vocabulary. Forty-one lines added.
• #9: a venture I’d removed the day before came back with a narrower focus, its two former standalone ventures folded under it as sub-brands. Sixteen lines. I changed my mind, and changing my mind cost sixteen lines.
• #10: Make First had gone live at its own domain, so the Learn page, the home carousel, and the About page were updated to say so, and a sub-brand whose site had just started returning a real response got its link. Fifty-four lines.

Each was its own branch, its own verify run, its own pull request, its own review. Small batches, which is exactly what the 2024 DORA report says keeps delivery stable when AI is in the loop.

Saturday: three lines

Pull request #11 changed three lines. A leftover count of thirteen ventures in one blog post became “a dozen,” and a sub-brand’s status note was updated after its site had been returning a healthy response for a day.

I mention it because three-line pull requests are most of what a studio of one ships, and because the content guard now fails the build on that old count, so the mistake can’t come back.

What got cut, and why

A week is what you ship and what you decline to. From the spec’s out-of-scope list:

• A Tailwind 4 migration. Real, deferred. It would have doubled the diff for no visible change.
• Newsletter and analytics. Both would need a privacy policy update. Not this week.
• Individual venture pages. The data model supports them. The ventures aren’t far enough along to deserve them.
• A paid Foundry tier and a partner track. Not real yet, so not on the site.

Scope cutting in a studio of one is less noble than it sounds. I don’t have a roadmap meeting to defend a feature in. I have Monday’s question: what moves a venture to the next status with the hours I have? Everything else waits, and I try to write down that it’s waiting.

What broke

The March build failure is the honest one, and it’s worth sitting with. A dependency upgrade merged in March never deployed, and for five months the main branch and the live site disagreed. Nothing told me, because nothing was checking.

That’s the failure the week was really about. The repositioning was the visible work. The type check in the build, the content guard, the link checker, and the one command that runs all of them are the durable work, because they turn “nothing told me” into “the build fails.” Every one of the later pull requests that week was small and calm because of the Thursday morning spent on plumbing.

What you can copy

None of this depends on my tools. The practices are:

1. Write the decisions down before the code. A table of claims with yes or no next to each. It’s the best prompt you’ll ever write, and it’s reusable as a guard.
2. One command that says pass or fail. Types, build, whatever guards you have. Give it to the agent and let the agent run it until it passes.
3. Turn every past mistake into a build failure. A forbidden-strings list is twenty lines of script and it never sleeps.
4. Small pull requests, one branch each, a human on every diff. Yours, if you’re alone.
5. Fix the plumbing first. If the build isn’t trustworthy, nothing shipped on top of it is either.

The stack I did this with is on the Platform page and the tools I reach for are in the Stockyard. The next post in this series is about the part of the job agents don’t do at all: deciding what to build in the first place.

---

This is the third post in the Studio of One series. Previous: Vibe Coding Gets You a Demo. This Gets You to Production. The tools are described in Building the Fractary Platform.