After 15 Years in WordPress, I Didn't Use It for My Sister's Site
My sister needed a website.
She had already bought a domain and WordPress hosting, which sounds like most of the job should have been done. Instead, she logged in and found around 50 plugins preinstalled, upgrade notices everywhere, and a dashboard that assumed she already knew what half of it meant.
She couldn't figure out how to build the site.
I've worked with WordPress for more than 15 years. I built plugins, helped grow WPMU DEV, and made a career out of solving WordPress problems. So naturally, she asked me for help.
I opened the setup and had an uncomfortable thought: I didn't want to build her site with WordPress either.
Ten minutes later, she had a fast static site running on Cloudflare Pages, built with a few prompts in Codex using the ChatGPT subscription she already paid for.
The problem was not WordPress itself
WordPress can still build almost anything. That is both its strength and its problem.
My sister did not need almost anything. She needed an attractive home for her writing, speaking, coaching, books, and contact information. It needed to be fast, secure, inexpensive, and easy to update a few times a year.
The hosting company had given her a toolbox full of choices before she had made a single decision:
- Which theme?
- Which page builder?
- Which form plugin?
- Which SEO plugin?
- Which security plugin?
- Which backup plugin?
- Which of the 50 preinstalled plugins were useful, paid upgrades, or just clutter?
That flexibility was not empowering her. It was transferring every product decision to her.
WordPress used to feel like the shortcut. For this job, it felt like the long way around.
I gave the agent the whole job
I didn't start by asking Codex to make a pretty homepage.
First, I gave it my sister's name and existing online presence and asked it to research her work. It collected the themes she writes and speaks about, the audiences she serves, her books and resources, and the way she already describes herself online.
Then it proposed the information architecture and content plan before writing code.
That ordering mattered. A website is not a pile of components. It is an argument about who someone is, what they do, and what a visitor should do next.
Once the plan looked right, Codex built the static site, connected the assets, and deployed it to Cloudflare Pages. No database. No plugin updates. No WordPress admin. Almost no attack surface.
The result was not merely "AI made a landing page." The useful part was that one agent could move from research to positioning to content to implementation to deployment without dropping the context between five different tools.
The update experience changed too
The biggest win is not that I built it in ten minutes. The biggest win is how she can maintain it.
When she wants to add a speaking event, change a paragraph, or publish a new resource, she does not have to remember where that setting lives. She can tell ChatGPT what she wants changed in normal language.
The implementation becomes a detail handled by the agent.
That is a completely different interface for owning a website. Instead of learning the tool's mental model, she can describe the outcome.
For a site that changes occasionally and does not need complex dynamic features, that feels much closer to the original promise of a website builder.
The post hit a nerve
When I shared this on X, the response was much bigger than I expected.
Some people saw it as evidence that WordPress had become too complicated. Others correctly pointed out that my sister had a hidden advantage: her brother knew how to choose Cloudflare Pages, set up the repository, review the output, connect the domain, and fix anything that broke.
One essay responding to my post called this the "duct-tape era" of AI website building. I think that criticism is fair.
My sister did not suddenly become a developer. She got a technical person to set up an agentic workflow for her. If the deployment breaks in a strange way, she is still probably calling me.
But that does not make the shift unimportant.
The amount of technical help required dropped from "build and maintain this website for me" to "set up a reliable path once, then let me request changes myself." That is a huge reduction in dependency, even if it is not zero.
Why not WordPress?
This is not my obituary for WordPress.
If my sister needed memberships, ecommerce, editorial workflows, a large plugin ecosystem, or a nontechnical agency that could take over tomorrow, WordPress might still be the right answer. It remains one of the most capable and transferable platforms on the web.
But capability is not the same thing as fit.
For a simple personal or small-business site, I now ask different questions:
- Does this need a database at all?
- Will the owner actually use a visual admin interface?
- Could an agent safely make the few changes they need?
- Who owns the system when the agent gets stuck?
- Are we choosing a platform for today's job or for every imaginary future job?
For Elisa's site, a static build plus an AI coding agent was the simpler product.
That is the part I think the WordPress community should take seriously. The competition is not only Wix, Squarespace, Webflow, or another CMS. The new competition is a conversation that produces and maintains exactly the software someone needs.
The old question was, "Which website builder should I learn?"
The new question might be, "Why should I have to learn the builder at all?"
I spent a big part of my career helping WordPress democratize publishing. I still care deeply about that mission.
But on this project, the most democratic option was not teaching my sister another dashboard. It was letting her describe what she wanted and giving the agent the keys.