How I build

A PRD before any code

Each project starts as a written spec: who it is for, what it has to do, and what is out of scope. Open questions go in a decisions file and stay there until answered. The agent is told not to guess them.

Rules the agent reads every time

A CLAUDE.md file holds the stack, the design system, the writing rules, and the confidentiality rules. A lessons file records every mistake and its fix, so the same one does not repeat. This site's own rules file bans client spend, contract terms, and names that have not been cleared.

One checkpoint per session, with a gate

Each session has one job and ends at a gate I check myself. This site was built that way: scaffold and content rules, then the project explorer, then the home page and timeline, then these pages. A session that drifts gets ended and restarted from the same prompt.

The gate is automated, not a vibe

On this site, every deploy validates each content file, fails the build on a malformed one, and searches the finished build for text from private notes. Right now that scan covers 46 phrases across 28 content files. Nothing is published until I set a file to public, so a draft cannot leak by accident.

The checks earn their keep. While building this site, a test caught date handling that read a year as a number and would have rejected valid files. The leak scan was proven by planting a fake private note and watching the deploy fail.

Staging before production, pilot before rollout

Every change gets a preview URL before it reaches the live site. For client work, the same rule applies to people: one location or one client runs the new system first, with the criteria for stopping written down before the pilot starts.

The tools

I use whatever does the job: Claude Code, Cursor, GitHub Copilot, v0, Bolt, Claude Design, the Claude API, OpenAI, Gemini, and Grok. The method matters more than the model. The rules file, the checkpoints, and the gate work the same whichever one is driving.