StrategIQ. Unconventional leadership. Exceptional results.

Field notes  /  Building with Claude Code

What AI missed on two clinic website builds.

I built two clinic websites with Claude Code in parallel in about a month, as one person running a set of AI sessions. The sessions wrote, tested, and reviewed the code, and they still missed things. These are the misses, what caught each one, and what changed in the process afterward.

Drawn from
OccMed Physicians and Direct Pediatrics
Full process
How I build a client app or site with Claude Code
Updated
November 2026

01  /  The process

The process drifted the moment nothing enforced it.

After four plans on the full workflow, the main session made 28 commits straight from my preview feedback with no spec, no plan, and no review. The repo had no CLAUDE.md, so nothing told a new session what the process was.

A session follows the process only if it reads the process in a file first. My own discipline did not help, because the session cannot see it. Both projects now carry a CLAUDE.md that every session reads first, with the records, the review process, the stops, and the rule against inventing facts.

02  /  Missing content

A page can look finished and still be missing the content.

On one build, the old Media page was redirected to the home page because “the captured page holds only the shared navigation.” It held 20 newsletters, a podcast, three books, and four videos that the capture never saw. Nobody noticed until the client asked what had happened to the practice's video.

Every item on the old site now gets an inventory row. A test fails if a carried item leaves its page, or if a dropped item has no named, dated decision.

The same thing happens on a single page. Claude will produce a clean page and report it finished. When I compared one to the original, my reaction was: “If I'm the clinician, I'm going to look at the new page and go ‘where did everything go?’” Only a person asking what the clinician would think can answer that.

A spec can be wrong in the same way. One misread the old page and dropped a visible fact as if it had been hidden copy. The final review, on a third model, caught it.

03  /  Code review

A model that did not write the code caught what the writer would have shipped.

A separate model reviews each task before its commit, and a third model that has not seen the work being produced reviews the whole plan at the end. These are some of the catches.

  • A regex read $1900 as 190.
  • An analytics config would have sent a form value to Google on the second click.
  • A thumbnail was lazy-loaded because “the spec had said lazy everywhere,” even though it was the page's largest paint.
  • A test asserted nothing, because the thing it checked for had been renamed.
  • An automated synchronization matched a form's paragraphs one slot off and overwrote them, so the live form showed the wrong text. The whole-branch review caught it the same hour, and the paragraphs are now pinned by name.

04  /  Looking at the site

The reviews read the code. Somebody still had to look at the site.

Implementers cannot see the built site and reviewers read code, so some defects pass every review. The main session builds the site and measures it at 375 by 812 before 1440 by 900, and I review every page on a phone.

  • Three titles looked bolder and pixelated because a 600 weight was never loaded and the browser faked it.
  • A hero button sat directly above its twin in the phone action bar.
  • A column measured 327px while the lead image was still 797px, and the page scrolled out to 822px. The review had passed that task.

05  /  Copy and facts

Copy drifted toward the generic, and conflicting facts went unflagged.

Claude writes lines that are fine and not right. I pushed on them one at a time: “Drop concierge.” “A stat is not exactly a ‘let us partner with you’ closer.” “An empty lobby says the opposite.” Each of those is a decision row. New copy now goes through an audit table with a Decision column for approve, strike, or my edit, and nothing is applied until I decide.

Facts were a separate problem. One old site priced the same service two ways on two pages, and the other published its hours three ways. A build carries that kind of contradiction forward without comment. It now goes on the unverified list for the client to close, and what nobody confirmed was pulled from the launch build rather than published.

06  /  Launch day

Launch day added four items to the playbook.

  • A DNS sweep missed three records that the zone export held, so the export is now mandatory.
  • The old platform kept serving the bare domain for 20 minutes after its record was deleted.
  • The old preview address stayed reachable and indexable for a week.
  • One form's routing decision turned out to be wrong. Nothing was broken, and a person noticed the next morning.

07  /  What changed

Every catch becomes a test or a written rule.

A ruling that lives only in chat is gone by the next session, so each catch goes into a test or a record that the next session reads. The content tests exist because a person caught something once and said it must not happen again.

Claude will offer to loosen a test, widen a regex, or add an exception. The answer is no. I fix the copy and leave the test alone, because loosening the test deletes the lesson.

How I build a client app or site with Claude Code