Building my own site with Claude agents.

I rebuilt maxdevos.be with Claude agents doing most of the typing. Not a demo — the site you're reading this on. This is the build log: what the setup looked like, what worked, and what bit.

The pipeline, end to end:

Kit first, pages second

Before any site code existed, we built a brand bible: one HTML document that holds the design tokens — colours pulled from the logo, type scale, spacing, motion — plus every component rendered live on the page. Nav, cards, buttons, code blocks, all documented once.

That file turned out to be the most important piece of infrastructure in the project. tokens.css is the single source of truth; the Nuxt app imports it unchanged. When a page needed a card or a CTA, the answer was "assemble it from the bible", never "design something new". That constraint did more for visual consistency than any review pass.

A deliberately boring stack

Nuxt 4. Marketing pages prerender to static HTML. Field notes are Markdown files rendered by Nuxt Content. The whole thing runs on the shared hosting I already pay for — a Node instance at my existing host, no new infrastructure, no platform to learn.

The tempting move was a shiny edge platform. The honest move was using what was already there and spending the energy on content instead.

Agents in parallel

Once the kit existed, pages became independent jobs. One subagent built the services page while another built the about page, each reading the same tokens and the same component CSS. They didn't step on each other, because they didn't share anything except the kit.

That's the real lesson about parallel agents: parallelism works when the shared contract is strong. Where the contract is vague, agents invent — and two agents inventing independently diverge fast.

Verify by rendering

The single most useful habit we adopted: never trust a description of visual work. Every change got screenshotted against the actual rendered page and looked at with human eyes.

More than once, an animation that sounded right in prose read completely differently on screen — a letter-scramble effect described as "subtle" was anything but. If we had merged on the description, it would have shipped. Screenshots are cheap; un-shipping an ugly animation is not.

What bit: drift

The brand bible contains a mock of the site navigation; the site has the real nav component. Two files, one design — and they drifted. A CTA changed in one and not the other. Nothing broke; it was just quietly wrong until a screenshot comparison caught it.

The rule since then: nav changes land in both files in the same commit, and the rule is written down where the agents read it. Duplicated truth needs a written rule, or it rots.

Staging that can't leak

The site lived on a staging subdomain while content landed, and I didn't want a half-finished site in a search index. One noindex meta tag felt thin, so the staging build flips three layers at once: a robots.txt that disallows everything, a noindex injected by the SEO module, and a hardcoded robots meta as belt-and-braces. A refactor might silently drop one layer; it's unlikely to drop all three.

If you're doing the same

Build the kit before the pages — agents are only as consistent as the contract you hand them. Keep the dynamic parts few and boring. And render everything: an agent's summary of what it built is a claim, not evidence.