Why I Don't Build on WordPress

I don't build on WordPress. Not for new sites, not for rebuilds, and never as the thing I migrate a business onto. That's a firm position, and I'd rather state it plainly and show my reasoning than pretend I'm neutral about a tool I've decided against.

This isn't tribal. WordPress runs an enormous share of the web and plenty of it works fine. My objection is specific and it's about the small-service-business case in particular — because that's who I build for, and for that customer the typical WordPress setup is a bad trade dressed up as a safe default.

The receipt: what the WordPress retainer actually buys

Ask a small business what their monthly WordPress bill covers and the honest itemization is uncomfortable. A large share of it is plugin updates — keeping a stack of third-party add-ons from breaking each other. Some is theme maintenance, patching conflicts between components that were never designed to work together. And there's usually an "SEO" line that, when you look, resolves to an SEO plugin someone installed years ago and hasn't touched since.

That's the racket, and it's not malicious so much as structural: the architecture creates the maintenance, and the maintenance is the retainer. You're paying, month after month, to keep a fragile thing from falling over. That's insurance against a stack you didn't have to choose. It is not the same as paying for work that grows your business, and the test for the difference is one question — show me what shipped last month — that a maintenance retainer can't answer well.

Fragility is a feature of the design, not bad luck

The failures aren't random. A site assembled from a dozen independently-updated plugins on shared hosting has a dozen things that can break each other, and an auto-update at an inconvenient hour is doing exactly what the architecture allows. When these sites go down, it isn't misfortune — it's the design working as designed. The more plugins bolted on to reach the feature you wanted, the more the surface area for the next conflict grows.

The customer-facing cost of all that machinery is speed. A page assembled on every request, running database queries and plugin logic between the tap and the paint, is slower than one that did its work in advance — and speed is a leads problem before it's a rankings problem. You can bolt caching plugins on top to paper over it, which is, of course, another plugin, another update, another thing to maintain.

What I ship instead, and why it doesn't crash

My stack is static-first and hand-built: pages are assembled ahead of time and served fast, there's no sprawling plugin surface to conflict with itself, and there's no 2 a.m. auto-update that can take the site down. It doesn't have the failure chain because it doesn't have the architecture that produces the chain. That's not a clever optimization — it's the absence of a whole category of problem.

The full picture of the stack, and why it holds up in the third year and not just on demo day, is on the studio page. If you're on WordPress now and tired of paying to keep it standing, the honest first step is figuring out whether a rebuild is worth it for your situation — and I'll tell you straight if it isn't yet. Inquire about a project →