As you might know, I recently came back to my business (after an admittedly rather short break).

One of the things about making this fresh start is that everything was up for review. Not just what I teach and how, but the tools I use to run the whole thing. Including this website.

For the longest time, I’ve built my sites in WordPress. If you’ve followed me for a while, you’ll know me for WordPress and page builders – Elementor, and more recently Bricks. So the obvious move would have been to spin up a new WordPress install, open a page builder and get going.

This time, I didn’t. And I want to tell you why, how I built it instead, and what I think it means if you’re not a coder.

This isn’t a “WordPress is dead” post

Let me get this out of the way first. I still think WordPress is valuable. It’s a brilliant CMS, and for a lot of sites it’s still exactly the right choice.

I just didn’t want to do what I’d always done on autopilot.

My requirements for this site are fairly small. A handful of pages, a blog, a sales page for my workshop, some sign-up forms.

And I knew that AI had made something else possible: designing and building a site with an AI developer, working to my own conventions and best practice.

My honest feelings about page builders

I’ve been building websites since 1998, and professionally since 2003. For the last ten years or so, I’ve taught thousands of people to build websites with page builders. Most of them weren’t coders, and didn’t want to be.

The promise of page builders was always that anyone could build a website. Just drag and drop. No code required.

And in fairness, plenty of people have been freed up by that. But in my experience, I’ve seen just as much frustration.

You drag an element onto the canvas, click into it and change its settings. Fine. But you only get the settings the page builder’s developers thought to give you. If they didn’t think of your particular need, you’re stuck.

And being stuck is often more frustrating than never having started, because you can see what you want and you still can’t get there.

Then there’s the clicking. Into a menu, into another menu, into a tab inside that, hunting for the one setting you need. Something you could write in a single line of CSS ends up as a dozen clicks across three panels. I ended up with RSI in my trackpad hand. I can’t prove page builders were to blame. But I can’t prove they weren’t, either.

And most page builders are proprietary. You’re working with their way of doing things, not directly with HTML and CSS. What you learn is partly tied to that one tool.

So what did I build instead?

The site you’re reading now is a static site, designed and built with Claude Code.

No design or planning happened beforehand. I opened a chat and off we went. The first, small version went live the next day, and it’s been growing ever since.

Here’s the stack:

  • Astro, which puts the site together from reusable pieces and turns it into plain, fast HTML pages.
  • Git, a version control system, which records every change, with a private copy on GitHub.
  • Cloudflare, which builds the site and hosts it. For free.
  • Claude Code, which writes the code. I’m on the $20 Claude Pro plan.

Why Astro?

I’m happy to admit it: I don’t know how to build websites in Astro. That’s not really the point.

What I like about it is that it brings over a lot of what I rely on in WordPress: templates and reusable components (for example, one header, one footer, one blog post template, and one “book your place” box for my workshop that appears on several pages), so a site stays consistent and is easy to maintain and extend as it grows.

And it doesn’t tie me to a CMS. Right now, I don’t need one. Blog posts like this one are just text files (Markdown) that sit in the project in a folder on my Mac alongside everything else.

If I need a CMS later, I can pick whichever one suits: Sanity, Keystatic, even WordPress. That’s a decision for later, not one I had to make on day one.

Local, staging and live

If you’ve built client sites, you’ll know how important it is to have separate local, staging and live versions. You’ll also know how fiddly it can be to set up and keep in sync.

Here, it’s built in:

  1. Local. Changes happen on my computer first, and I preview them in my browser as we go.
  2. Staging. When I’m happy, the changes go to a staging branch on GitHub. Cloudflare builds that into a private test copy of the site, hidden from search engines, where I check everything properly.
  3. Live. When I’m ready, I push staging to the main branch, and Cloudflare builds that into davefoy.com.

That last step is mine alone, and it takes a few seconds. My AI developer never publishes to the live site.

Meet Kit (and the rest of the team)

When I came back, I also set up a small AI team.

There’s Ren, my chief of staff, who looks after strategy and priorities. And there’s Kit, my web designer and developer, who builds the site with me.

I won’t go down that rabbit hole here, but if you’re curious, you can meet the whole team. They’re a good-looking bunch, I think you’ll agree.

I’ve done all of this in the Claude desktop app, often with several Claude Code sessions going at once. No VS Code, no Cursor, no fiddling about in a terminal.

I haven’t written a single line of code. OK, one. And I didn’t even write that – I just paste it in. Pushing staging to live is a single Git command, and I’ve saved it as a Raycast snippet. I type ;gitpush and it expands into the command. That’s it.

Here’s the important bit, though

You might be reading this thinking:

“Great, so AI does it all now, and we don’t need page builders or skills.”

That’s not what I’m saying at all. In fact, quite the opposite.

Yes, AI means a non-coder can now build a website without a page builder. But I think you need a solid workflow, good conventions, best practice and a real understanding of what’s going on more than ever. Without them, you get a site that looks fine today and is a nightmare to maintain, extend or keep consistent tomorrow.

I didn’t hand the site over to Kit and say “get on with it”. The decisions have been mine – my conventions and best practice, built up over more than twenty years – and much of the work has been going backwards and forwards with Kit to work out what those decisions actually are, then writing them down so they stick.

Here’s what that looks like in practice.

A design system with rules that can’t be broken

In the first week, the site was built the way a lot of sites are: sizes, spacing and colours set wherever they were needed. Before long, there were hundreds of one-off values.

And that was fine for experimenting. But there was no way that was carrying on on my watch.

So we stopped and built a proper design system. Rather than buy an off-the-shelf framework, I decided we’d make our own, following my own naming conventions. Every font size, space and colour on the site now comes from one small settings file of named values (called “tokens”, or you might know them as CSS variables).

Then we made this a rule the computer enforces, not just a guideline. If Kit tries to use a size or colour that isn’t in the system, the build stops. The site literally won’t publish. And he gets a stern look from me.

And we wrote down a second rule: if a design needs something the system doesn’t have, Kit has to stop and ask me first. Either we add it to the system properly, or we agree a one-off exception, which gets marked in the code and listed so we can tidy it up later. No silent one-offs.

You can see the whole design system if you’re curious.

Small decisions, written down

A lot of the decisions are tiny, and they’re still mine. Two font weights looked identical side by side, so we moved them further apart. The body text was 17px on phones until I found it a little small on my iPhone, so it went back to 18px. I chose white text on the main buttons. I decided this site uses spaced en dashes – like this – rather than em dashes.

None of those are things an AI would have known about me. Each one went into a project file, so it’s applied consistently from then on.

Files that do the remembering

AI doesn’t remember your last chat. So everything important lives in a few plain text files in the website folder:

  • A role file that tells Kit who he is, what he’s responsible for and how I like to work. Every session starts with it.
  • PRODUCT.md, covering who the site is for, my voice and the claims we never make.
  • DESIGN.md, with every visual decision and design rule.
  • STATUS.md, a running log of what’s been built, what’s live and what’s next.

STATUS.md is also how Kit and Ren talk to each other. Ren, my chief of staff, works in a different folder, my “Business OS”, where the business strategy lives. When something the business needs affects the website, Ren writes it into STATUS.md. Kit picks it up in the next session, builds it and marks it done. And when Kit changes something Ren needs to know about, like a launch date or how sign-ups are tracked, it goes in a section for Ren.

That means nothing depends on anyone remembering anything. Including me. My memory is terrible. 🙃

Impeccable

For the design side, we’ve used a design skill for Claude Code called Impeccable. It’s what gave us the structure for PRODUCT.md and DESIGN.md in the first place, and a place to record the direction for individual pages.

I honestly can’t tell you how it would have gone without it, because we never tried. But I’ve enjoyed the process, and I like having that structure to work to. It gave us somewhere to codify design and product decisions as we made them, rather than leaving them in my head.

One setting to switch a sales page

My AI Agency workshop page has two states: a sales page while the doors are open, and a “register your interest” page while they’re closed.

In my previous WordPress setup, switching between them meant editing a page, switching page slugs, maybe updating a few other pages and remembering the sharing image. Here, it’s one setting. Change it from “sales” to “interest”, and immediately the sales page becomes the interest page, the workshop boxes on the home and Training pages change to match, and so does the image people see when the page is shared on social media. That makes closing the cart on a launch a hell of a lot easier and quicker.

And speaking of sharing images, every page and blog post gets its own social sharing image, generated automatically every time the site is built. I never have to open a graphics editor to make one.

So, should you ditch your page builder?

Not necessarily. If you’re happy and productive with your page builder, carry on.

But if you’ve ever felt boxed in by one, it’s worth knowing there’s another way now. Just know that the AI isn’t what makes this work. The conventions, the workflow and the decisions behind it are. That part is still yours.

If you want all the nerdy details in one place, I keep a colophon with everything that powers this site, and I’ll keep it up to date as things change.