Static Sites vs. WordPress

The site you’re reading was WordPress until May

labean.org doesn’t need frequent content updates from multiple people. It’s not taking payments. It’s not running a membership tier or publishing three posts a week. It’s a résumé and portfolio site with content that changes in bursts — a new project added, a bio updated, an old client swapped out — maybe a handful of times a year. Every plugin update, every login page exposed to the internet, every PHP version bump was overhead I was carrying for editing convenience I wasn’t using. So I dropped the CMS layer entirely. The pages are just pages now. There’s nothing to patch and nothing to log into.

That’s the whole exercise, honestly. Not “static beats WordPress.” Just: what does this specific site actually need to do, and what’s the least amount of moving parts required to do it well.

Is WordPress still worth using? Yes — sometimes

WordPress still runs a huge share of the web, and for good reason. It solved a real problem: letting non-developers manage content without touching code, and letting developers extend that with a plugin ecosystem deep enough to cover almost any feature a client might ask for. That’s not nothing. I’ve built and maintained WordPress sites for small businesses and marketing teams for a long time, and I still list it as a core skill for a reason — it’s the right tool often enough that dismissing it outright would be its own kind of bias.

The question isn’t whether WordPress is good. It’s whether it’s good for this project. And that depends on things that have nothing to do with which platform is more modern.

When WordPress is the right call

WordPress earns its complexity when the complexity is actually being used. A few signals I look for:

• Multiple editors. If more than one person needs to log in and publish — a marketing team, an office manager, a client’s assistant — a CMS with roles and permissions isn’t overhead, it’s the feature you’re paying for.
• Frequent content changes. A blog publishing weekly, a news section, an events calendar that turns over constantly — that’s a workflow problem, and WordPress’s editorial tools solve it well.
• Memberships and ecommerce. Gated content, subscriptions, product catalogs, checkout flows — these require real backend logic, and WordPress’s plugin ecosystem (WooCommerce, membership plugins, and the rest) means you’re not building that logic from scratch.
• Large blogs or content libraries. Once you’re managing hundreds of posts with categories, tags, search, and internal linking at scale, a database-backed CMS is doing genuine work for you.
• Marketing teams that need independence. If the client’s team needs to launch landing pages, run A/B tests, or update copy without filing a ticket to a developer, that autonomy is worth the maintenance tradeoff.

In all of these cases, the ongoing cost of hosting, updates, and security patching is the price of a capability the project actually needs. That’s a fair trade.

When static wins

Static sites win when the project’s real requirements are simpler than the platform being considered for it. A few signals in the other direction:

• Security. A static site has no database to inject, no admin panel to brute-force, no plugin with an unpatched vulnerability sitting on the server. The attack surface is close to zero because there’s nothing dynamic to attack.
• Speed. Serving pre-built HTML means no server-side rendering, no database query, no plugin stack running on every page load. It’s just faster, by default, without needing a caching layer bolted on to get there.
• Lower maintenance. No core updates. No plugin conflicts after an update breaks a theme. No 2 a.m. email about the site being down because of a failed automatic update. Once it’s built, it mostly stays built.
• Lower hosting costs. Static files can be served from cheap, simple, highly reliable hosting — no PHP runtime or managed database required.
• Small business websites, landing pages, portfolios. When the content is a handful of pages that change occasionally — hours, services, an about page, a portfolio, a contact form — a CMS is solving a content-velocity problem the site doesn’t have.

I build a lot of sites in this category: studios, restaurants, attorneys, ministries, local publications. Businesses that need a strong, credible web presence but aren’t publishing daily and don’t have a content team. For most of them, static isn’t a compromise — it’s a better fit than WordPress would have been, and it’s part of why the language on this site itself has shifted over time from leading with “WordPress development” toward broader “website development.” Not every client site I build runs on WordPress anymore, and that shift reflects the work, not a rebrand.

The real question isn’t WordPress vs. static

Framed as a platform contest, this becomes a debate about which tool is more powerful, more modern, more popular. None of that is the actual question. The actual question is: what does this project need to do, who needs to maintain it, and what’s the least complexity required to make that happen reliably?

Sometimes the answer is a CMS with editorial workflows and a plugin for everything. Sometimes it’s a folder of hand-written HTML that never needs a login page. Neither answer says anything about which technology is better in the abstract — only about which one is appropriate here, for this client, with this content, maintained by these people. Get that assessment right and the platform choice mostly makes itself.

Favorite outcomes, not favorite tools

I don’t have a favorite platform. I have a favorite result: a site that does what it’s supposed to do, stays secure without babysitting, and doesn’t cost the client more — in dollars or attention — than the problem it’s solving requires.

Some projects get there on WordPress. This one got there by leaving it. The judgment call is the same either way.