If you think AI will let you build a good website without thinking harder, this probably isn’t for you.
I don’t mean that provocatively. I mean it literally.
Halfway through this build, I nearly gave up.
I was debugging a custom block that wouldn’t render. The AI had confidently broken something it built an hour earlier. And I caught myself thinking: I could do this the old way and be finished by now.
That moment mattered, because it surfaced an uncomfortable truth I hadn’t fully accepted yet:
AI doesn’t reduce thinking. It exposes where you haven’t done enough of it.
I didn’t quit. The site is live. It was built in under three weeks, with a content structure that would have taken me much longer to assemble by hand. The client is happy.
But it was harder than I expected — and that difficulty is the point.
What I actually did (and what I didn’t)
This wasn’t one of the “describe your business and we’ll build your site” tools.
I’ve seen those. They’re fast, and they’re fine — until you look closely. Same templates. Same assumptions. Same generic structure, just rearranged.
This build worked differently.
I made the decisions:
- how the content should be structured
- what components needed to exist
- how pages would evolve over time
- where future change was likely to occur
The AI executed those decisions faster than I could manually. It wrote the code. It populated the content. It helped debug when things broke.
And things did break.
Sometimes the AI fixed problems cleanly. Sometimes it confidently introduced new ones. When my direction was unclear, the output was unclear. When the context got too large, progress slowed. When I went down the wrong path, the AI followed me there politely instead of pushing back.
That wasn’t a tooling problem. It was a thinking problem.
Human judgment, AI execution.
That’s the distinction that matters.
Why I still chose WordPress
WordPress isn’t fashionable to defend, but it remains unmatched if you care about long-term flexibility.
It’s open source. Self-hosted. Portable. You’re not renting your site from a platform that can change pricing, limits, or priorities overnight.
The usual complaints — bloated, slow, fragile — are almost always symptoms of how sites are built, not what they’re built on.
A site assembled from themes, plugins, and assumptions behaves very differently from one designed as a system. One breaks when reality changes. The other adapts.
That difference only becomes obvious after launch — which is why most people don’t notice it until it’s too late.
Where this got hard (and why that matters)
I built everything with custom blocks — reusable components that do exactly what they need to do and nothing more.
That’s where modern WordPress is heading, but it was my first time building blocks this way. Early design decisions I didn’t validate properly created friction all the way through the build. There were rabbit holes. Some were useful. Some weren’t.
The AI helped, but it didn’t save me from those mistakes. It amplified them.
When I gave it poor direction, I got poor output. When I allowed complexity to creep in unchecked, it happily supported that too.
The lesson wasn’t “AI isn’t ready.”
It was this:
Speed without architecture just moves the pain downstream.
Why I didn’t walk away
Because of what this approach makes possible after launch.
Most websites are fragile. They’re built on assumptions about customers, messaging, offers, and structure. Those assumptions get baked in early. And when reality shifts — which it always does — change becomes expensive.
You either rebuild, or you live with a site that no longer fits.
A site built this way behaves differently.
The same system that slowed me down initially now makes change cheap:
- content updates across the site take hours, not days
- structural changes don’t require rework
- new pages don’t force redesigns
- pivots are possible without starting over
Your website is still the only online asset you actually own. Everything else — social platforms, directories, AI-mediated discovery — is rented.
The real value of that owned asset isn’t how it performs today.
It’s how quickly it can respond when you learn something new tomorrow.
What I learned (and why it compounds)
Every hard part of this build became protocol.
The mistakes I made — skipping design validation too early, overcomplicating block architecture, not pushing back hard enough on complexity — are now documented with fixes.
The next build won’t hit those same walls.
More importantly, the learning transfers. The way of thinking does. The system improves itself.
The first time through was hard.
The second will be faster.
The third faster again.
That isn’t optimism. It’s how compounding systems behave.
Who this is not for
If you want a site that looks fine and ticks a box, this is probably unnecessary. A template and a prompt will get you there faster, and that’s a perfectly rational choice.
But if your website needs to:
- support real sales conversations
- evolve as you learn what resonates
- remain useful as AI reshapes how buyers discover you
…then how it’s built matters as much as how it looks.
If that tension sounds familiar, we should talk. If it doesn’t, you’ll save time by doing something simpler.
Both are valid outcomes — and that clarity is the point.
