~/writingrebuilding-matchlessweb
Rebuilding matchlessweb.com as The Changelog, and how I write its blog with AI
Five AI-built versions of my agency site, the one I kept, and the critic loop and automated fact check every blog post passes before it publishes.

matchlessweb.com is my agency's website, and this year I rebuilt it from scratch. I had AI agents design five different versions of it, picked one called The Changelog, and took it live in September. Then, on September 28, I added a blog, which I write with AI and run through two checks before anything publishes: a panel of critics that score each post blind against the best pages already answering its question, and an automated fact check a few days before it goes out.
Why build five versions of my own site?
I didn't want to take the first design Claude gave me, but I didn't need fifteen either, the way my fifteen-site test went. Five gave me real options, and I'm glad I had them: The Changelog wasn't the first design the agent produced, and I doubt I'd have landed on it otherwise.
The first round, in July, used Claude Fable 5 to build three complete versions of the site, all dark: The Engine Room, The Ledger and Night Shift. In September, a second round with Fable 5.1 built two more, The Changelog and The Survey, this time with both light and dark themes.
I picked The Changelog, number four, because it was the more finishable of the last two. Its idea is that the site reads like a versioned release history: a commit-graph line runs down the page, and sections reveal like a diff. I liked its typography (Geist and Geist Mono) and its palette.
What changed between the prototype and the live site?
A lot, and most of it was taking things out. My notes on the first version:
- Far fewer plus and minus signs. They stayed only in the before-and-after comparison.
- Much less git jargon. My clients are business owners, not developers, so no commit hashes, HEAD or version numbers.
- Far less scroll animation: the hero once, section headings once, and the line down the page.
- Add imagery. I turned down the first attempt, engraved technical drawings, and settled on two kinds by role: two-ink risograph illustrations for ideas, and duotone photographs for atmosphere. Real people and real client work are never AI-generated.
The copy got a rule too: first person singular everywhere. Matchless is me. When a project needs a specialist I bring in a contractor for that piece, but you always work directly with me, so the site says "I," never "we."
Every fact on the old site carried over through a written content contract, a single document that says what the site says. Prices, reviews and case-study text are verbatim; the builders decide how it looks.
Did it get faster?
Yes, measurably. After launch I did a performance pass: lazy-loaded illustrations, inlined font faces, image formats swapped to AVIF with WebP fallbacks. Lighthouse scored 100 on mobile and desktop on every page I audited. Phone downloads fell 51% on the home page and 63% on a solution page, and the largest content on each page painted in 0.8 to 1.3 seconds.
One result went against the usual advice. Marking the hero image as high priority measured worse than leaving it at the default, so I left it at the default. And one bug only showed up on iOS: Safari there ignored the CSS I used to mask the duotone photos, and drew a solid green block instead. The fix was a different image format for the masks.
How are the blog posts written?
With AI, and I'd rather say so than have you guess. Each post starts with research: the keyword data, the top ten search results, and the pages Google's AI answers cite for the question. Two of those pages become the rivals. An agent drafts the post, answer first, with question-shaped headings and one thing the rivals don't have.
Then five critics, each an AI reviewer, score my draft and the two rivals blind, without knowing which is mine, and each has to quote from the page it's scoring. The draft gets revised until it wins or hits a stopping rule. Then I read the preview and the scorecard, and I approve it or I don't. Nothing goes live without me reading it.
I write very little of it by hand. I dictate the themes and ideas and supply my own experience and work, which is the part an AI can't invent. The agent organizes and structures the rest.
What stops a wrong fact from publishing?
Posts are written weeks ahead, and facts go stale. So one to three days before a post's date, a GitHub Actions workflow has Claude re-check every claim in it against its source: figures, quotes, product and policy details, and links. It can fix a stale fact in the fewest words that make it true. It can't add claims, remove one it couldn't verify, or change the title.
If only the fact-check date changed, the post publishes on its date. If any words changed, it opens a pull request and the post waits for me. And the publisher itself holds any post whose fact check is more than seven days old, or that has a broken link.
The plan from here: two posts a week for six weeks, then one a week, each on its real date.
Stack: Claude Fable 5 and 5.1 (the builds), Geist and Geist Mono, Cloudflare Pages, SureContact (forms), Fathom (analytics), Lighthouse, Ahrefs (research), and GitHub Actions with Claude (fact check).
Jon Phillips builds websites, web apps and automations atMatchless Web in Clinton, Mississippi.


