The WordPress Problem
WordPress powers about 43% of the web. It also powers an enormous amount of slow, bloated, insecure, plugin-dependent websites that exist in a permanent state of "almost working." The typical WordPress site has a dozen plugins running on every page load, a theme that hasn't been updated since 2022, and a PageSpeed score that Google is actively penalizing.
That's not a knock on the people who built their sites that way — it was the reasonable choice for a long time. But the landscape has changed. The tools available now make it faster and cheaper to build something better than what WordPress gives you, without the maintenance burden.
The Stack That Replaced It
My current workflow for building client sites is: Claude for content architecture and initial code generation, Cursor for editing, refining, and iterating on the actual HTML and CSS, and Vercel for deployment. GitHub for version control throughout.
The output is a static HTML file — or a small set of them for multi-page sites. No server-side rendering. No database. No CMS. Just files sitting on Vercel's CDN, loading in under two seconds from anywhere in the world.
Why This Beats WordPress on Every Metric That Matters
| Metric | WordPress | Static HTML / Vercel |
|---|---|---|
| Page load time | 2–6 seconds typical | Under 1 second |
| PageSpeed score | Often 40–65/100 | 90–100/100 |
| Monthly hosting cost | $15–$60+/mo | $0 on Vercel free tier |
| Security vulnerabilities | Constant (plugins, themes) | No attack surface |
| Maintenance overhead | Ongoing updates, backups | None |
| You own the code | Sort of | Completely |
How the Workflow Actually Works
Step 1: Architecture with Claude
I start by describing the project to Claude — the client, the audience, the key goals of the site, and any design direction. Claude helps me think through the section structure, the content hierarchy, and even drafts initial copy. This isn't using AI as a crutch — it's using it the way a senior engineer uses it: to move through the boring parts faster so I can focus on the craft.
Step 2: Build in Cursor
I work directly in HTML and CSS inside Cursor. Cursor's AI-assisted editing lets me iterate on design decisions quickly — change a color system, refactor a layout, try a different typographic approach — without the friction that comes from fighting a theme's overrides or digging through someone else's plugin code.
Everything I write is intentional. There's no mystery about why something looks the way it does. I know every line of the code because I wrote every line of the code.
Step 3: Deploy on Vercel in 2 minutes
Push to GitHub, connect to Vercel, done. Automatic SSL. CDN-distributed globally. Custom domain in 5 minutes. The deployment story is genuinely zero-friction. No cPanel, no FTP, no "wait for DNS propagation while your client is refreshing every 30 seconds."
What About Content Updates?
The most common objection is: "What if the client wants to update their own content?" For most of the clients I work with — brokers, consultants, service professionals — the honest answer is: they don't. They want the site built right and then left alone.
For clients who genuinely need to manage content themselves, there are lightweight CMS options like Decap (formerly Netlify CMS) or Tina that sit on top of static HTML without introducing the full WordPress complexity stack. But I always ask the question first before defaulting to a CMS as the answer.
This Isn't Theoretical
I built Amanda Weaver's CRE platform using this exact workflow. Read that case study here. She got a faster, more professional site than anything a WordPress agency would have delivered — at a fraction of the time and cost — and she shared it to her entire LinkedIn network on launch day.
That's the argument. Not theoretical speed scores or philosophical disagreements about open source. Just better results, faster.