WordPress runs a huge share of small-business websites, and for most of them it's the wrong tool. It's slow because it queries a database and runs PHP on every single visitor request. It's a maintenance treadmill — plugins, updates, security patches, the 2am call when something breaks. And when a client wants to change a sentence, they either learn a page builder or they email their agency and wait.

Claude and I set out to build the thing that kills it — not "WordPress but ours," but a narrower, better product: an agency-owned platform where sites are lightning-fast by construction and clients can edit their own content in place, with no plugins, no database at request time, and no maintenance tax. This is Part 1 — the architecture. Part 2 will be the finished build.

What surprised me, doing this with an AI in the loop, is where the value actually landed. It wasn't the typing. It was the decisions.

The idea, and the first correction

My starting point was a business one: every site we deliver should come with a dashboard, and that dashboard should be a guided upsell surface — the client edits their site, and right next to that are the tabs for SEO, GEO, ads, lead capture, analytics. You land the account with the website and expand it from the same screen. (One refinement along the way: this is a dashboard feature, not a separate portal — it lives where the client already is.)

The first thing Claude built me was a content editor — a form on the left, a live preview on the right. It worked. It was also not what I wanted, and I said so: I don't want to edit content beside the page, I want to edit it on the page, the way Elementor or Divi feel. That correction reset the whole direction, and it was the right one.

Where experience earned its keep

A few calls shaped this project more than any line of code, and every one of them came from having done this before:

Rejecting the fast-but-wrong approach. The easy way to make an existing site "editable" is to paint new content over it with JavaScript at load time. Claude proposed it as one option. I killed it — because I know what that does to SEO. Google's reliable index is the initial HTML; content that only appears after a script runs is a gamble, and there's a flash of the old text on every load. If you care about ranking local service businesses, you do not paint. You write the real, final HTML.

Starting at the template level. Instead of bolting editing onto hand-built pages, I wanted the content model defined first — sites rendered from structured data, so editing, speed, and SEO all fall out of one decision. That sequencing (model first, features second) is the difference between a system and a pile of patches.

The two-mode insight. The thing that unlocked the editor design was realizing that "edit the page" is really two jobs: Edit Content (change the words, in place — safe, the client does this every day) and Edit Layout (add and reorder blocks — occasional, staff-guarded). Two modes, and the mode is the guardrail. That reframing dissolved a problem we'd been circling.

Deciding what not to build. The tempting feature is a full drag-and-drop layout builder. It's also exactly where these tools become bloated, un-themeable, and easy for clients to wreck. We drew a hard line: layout lives inside blocks, and there is no freeform layout builder. Restraint is a design decision, and it's one an AI won't make for you.

Bringing in a second opinion, and checking the world

Here's where the AI-in-the-loop workflow actually shone. Once the architecture felt right, I did two things I'd tell anyone to do: I ran the whole thing past a different model (ChatGPT) for an adversarial read, and I had it scan GitHub for anyone who'd already built this.

The second opinion was worth it — it caught that our document was strong on how the platform works and thin on the commercial workflow: permissions, approvals, what a client can safely touch. That's the part that turns elegant architecture into a sellable product, and we tightened it.

The landscape scan was the reassuring kind of answer. The ingredients — static generation, structured blocks, visual editing, multi-tenancy — are all proven and battle-tested. Our exact assembly is rare: agency-owned database as the source of truth, static output for speed, guarded in-place editing, and the dashboard as the upsell layer. Every off-the-shelf option forced a tradeoff we'd already rejected — storing content in Git, or running a second CMS, or handing clients a freeform builder. So the plan wasn't to invent primitives. It was to assemble proven parts into our specific operating model — and borrow shamelessly where someone had already solved a piece well.

The stack we landed on

The clarification that mattered most is one people get wrong constantly: "database or no database" is a false binary. WordPress is slow because it hits a database on every request. You beat it by hitting the database once at publish time and serving plain static HTML forever after. So we edit in a database (agency-owned, versioned) and serve static files. Same content, radically different speed.

From there it converged fast:

• Astro generates the sites — component-based, zero JavaScript by default, static output.
• Puck (an open-source, MIT-licensed React editor) is the editing surface — it does both our modes, saves to our own database, and edits our components. Not a CMS we have to adopt; an editor we embed.
• Shared React blocks — each block is written once and used by both the editor and the static build.
• Our existing dashboard stays the source of truth, the auth, the multi-tenancy, and the upsell layer.

Solving the hard problem first

The whole design rests on one bet: that a single block component can render in the editor and compile down to a fast static page. If that seam doesn't hold, nothing else matters. So instead of building outward and hoping, we built the riskiest piece first — a tiny proof.

The result: one shared component, edited through Puck's config, rendered by Astro to a static homepage that shipped zero JavaScript and weighed about one kilobyte — the entire page, HTML and styling included. For comparison, a typical WordPress page is hundreds of kilobytes plus a JavaScript pileup. That's not a marginal win. That's the ludicrous-speed the whole thing was named for, proven before we committed to the build.

Where the AI was invaluable — and where it wasn’t

I want to be honest about the division of labor, because the subtext of this whole project matters. Claude was a genuine force multiplier. It synthesized a landscape I'd have spent days reading, it produced the first working editors in minutes, it wrote the proof-of-concept and inspected its own output, and it held a coherent architecture across a dozen turns of me changing my mind. The best moments were technical: the database-vs-static clarification, the "layout lives inside blocks" discipline, spotting Puck and realizing one component could serve both surfaces, and designing the spike to de-risk the bet. That's real contribution, not autocomplete.

But the calls that steered the ship — kill the paint-on approach, define the model first, don't build the layout builder, get a second opinion, solve the hard part first — those came from experience. Knowing what to reject is still a human job. The AI will build almost anything you point it at, brilliantly and fast, which is exactly why pointing it at the right thing is the entire game.

So here's the honest version of the promise you'll see everywhere that "you don't need developers anymore": for the best outcomes, you still do — for now. What's changed is the multiplier. One person with real software judgment and an AI partner like Claude can now out-build a whole team that has the tools but not the taste. That's the story of this platform, and it's the story I keep living every week.

Part 2 is the finished machine: the block library, the two-mode editor live, a real client site built, edited, and published at that one-kilobyte weight — and what it's like to hand a small business the keys to a website that a developer would be proud of and that they can actually run themselves. See you there.