Why We Don't Use WordPress (and How That Saves You Money)

WordPress runs a huge chunk of the internet and it's not because it's great. It's because it got there first and it's easy to install.

We don't use it. Not on our own site. Not on any of our clients' sites. That's not a religious position; it's a practical one. Every WordPress site we've ever been asked to rescue had the same three problems: it was slow, it was insecure, and it was costing the owner real money every single month in ways they didn't fully understand. Static HTML solves all three for a fraction of the cost, and modern tooling has made the old "but clients can't edit their own site" argument mostly obsolete.

So here's the case, plainly. Why Reckless Media doesn't build on WordPress, what we build instead, and where WordPress would still be the right call.

The Honest Case Against WordPress

WordPress was designed in 2003 as a blogging platform. It grew into a full content management system by layering plugins on top of plugins on top of a PHP-and-database core. The software is fine. The way most small businesses end up using it is the problem.

A typical small-business WordPress site is running a theme from one developer, a page builder from another (Elementor, Divi, WPBakery), a form plugin, an SEO plugin, a security plugin, a caching plugin, a backup plugin, an image optimizer, and twelve other things the last agency installed and never documented. Each of those components updates on a different schedule and occasionally breaks the others. Somebody has to keep the whole thing running, and if you don't, your site eventually goes down or gets hacked.

That's not a theoretical risk. It's a monthly occurrence in our rescue work.

The Real Cost of a WordPress Site

Let's put numbers on it. Here's what a typical WordPress site actually costs a small business to operate per month, once you add up the pieces:

• Managed hosting. $25 to $80 a month for anything that actually stays fast (WP Engine, Kinsta, Flywheel). Budget hosts exist, but they get ugly at scale.
• Premium plugins. A page builder license, a forms plugin, an SEO plugin, and a security plugin adds $200 to $800 a year in licenses alone.
• Maintenance retainer. Whether you pay an agency or a "WordPress care" service, you're spending $50 to $200 a month for somebody to run updates, fix breaks, and handle the occasional emergency.
• Backups and security. Either rolled into maintenance or a separate $10 to $30 a month for a service that actually works.

Add it up. A real-world WordPress site runs $100 to $250 a month to operate, not counting development. Over five years that's $6,000 to $15,000 just to keep the lights on. That's before anybody has touched the design.

A static HTML site runs roughly $5 a month on basic cPanel hosting. Sometimes $10 if you're on faster infrastructure. Five years of that is maybe $600. For the exact same user-facing site.

You're not paying WordPress for a website. You're paying WordPress for the privilege of maintaining one.

The Security Situation Nobody Mentions

WordPress powers around 40% of the websites on the internet, which makes it the single biggest target for automated attacks. Every plugin you install expands the attack surface. Every abandoned plugin (and there are a lot of them) is a ticking vulnerability waiting for a patched exploit to become public.

The security plugin industry exists because the base product needs constant shoring up. Wordfence alone blocks billions of malicious login attempts per month across its installed base. That's not marketing copy; that's just the environment.

Here's what static HTML can't have:

• No database. No SQL injection. The most common class of web attacks simply doesn't apply.
• No plugins. No plugin-level CVEs. No "this bug was patched three months ago but the site never got updated."
• No login page for attackers to brute force. There's nothing to log into on the public site.
• No PHP runtime on the public side. Fewer code paths, fewer ways in.

Can a static site get compromised? Sure, at the hosting or DNS level. But the blast radius is dramatically smaller and the recovery is almost always just "redeploy the site." On a hacked WordPress site, you're often paying a forensic cleanup service to comb through a database looking for injected rows.

Speed Is a Feature, Not a Setting

The average WordPress small-business site loads somewhere between 4 and 8 seconds. A cleanly built static site loads in under a second on the same connection. That gap shows up in two places that matter: your Google rankings and your conversion rate.

Google's Core Web Vitals have been a confirmed ranking factor since 2021. Sites that hit green on the three vitals (LCP, CLS, INP) get preference over slower competitors for the same keywords. A sub-second static site hits green by default. A typical WordPress site limps across the line only after heavy caching, image optimization, and careful plugin management, and it regresses every time somebody installs something new.

On the conversion side, every additional second of load time costs you visitors. Studies vary, but the general finding is consistent: a 1-second delay can reduce conversions by 7 to 10%. A site that loads in 5 seconds instead of 1 is leaving a lot of leads on the table even before anybody clicks a CTA.

What We Build Instead

Every site we ship is hand-coded HTML, CSS, and JavaScript. No WordPress. No React. No CMS on the public side. Here's what that looks like in practice:

• Hand-coded pages. Every page is written to purpose. No theme baggage, no framework bloat, no code that ships to users just because some plugin needed it.
• cPanel or LiteSpeed hosting. The same affordable shared hosting your WordPress site is on, except we're not fighting it.
• GitHub Actions deploys. Every change is version-controlled. We push a commit, the site updates automatically. If something breaks, we roll back in 30 seconds.
• 90+ Lighthouse scores across the board. Performance, accessibility, best practices, SEO. Every site. Not as a stretch goal; as a baseline.
• Forms, analytics, and automation still work. We use modern third-party services for the dynamic stuff (forms, scheduling, email) instead of rolling it into a CMS.

The result is a site that loads faster, ranks higher, costs less to run, and doesn't wake anybody up at 2 a.m. because a plugin update broke the checkout.

The Tradeoffs (We're Not Pretending)

We're not here to tell you static HTML is magic. It's not the right answer for everybody. Here's what you actually give up:

• You can't edit the site yourself by default. On a static site, changes come through us. If you want to change a headline at midnight, you either send a request or we build you a small dashboard to handle specific editable zones.
• Adding complex dynamic features takes more work. If you need a full e-commerce checkout, a user-account system, or a forum, WordPress (or Shopify, or a proper app) is probably a better fit.
• No plugin shortcuts. Anything we add is built custom. That's a feature for quality and a constraint on turnaround time.

For most of our Arkansas clients (service businesses, local brands, agencies, professional practices) those tradeoffs don't hurt. Their sites change a few times a year and we handle it. They'd rather not have a CMS they don't use than a CMS that costs them every month.

When WordPress Is Actually Right

I'm not anti-WordPress as a universal rule. A few cases where we'd tell a client to use it (or use Shopify, or Webflow, or something else):

• You publish constantly and you edit your own posts. News sites, content-heavy blogs, publications. If 10+ people are writing and editing every week, a CMS earns its keep.
• You already have staff managing it well. If your team knows WordPress and has a working maintenance rhythm, the switching cost isn't worth it.
• You need deep e-commerce with thousands of SKUs. WooCommerce or (better) Shopify are purpose-built for that.
• You rely on a specific plugin ecosystem. Some membership, LMS, or booking plugins are genuinely the best options out there and only exist on WordPress.

Outside those cases, we haven't found a good reason to put a local Arkansas business on WordPress in years.

Fewer Moving Parts, Fewer Problems

The real case for building this way is philosophical. Every tool you add to your stack is a future problem in disguise. Every plugin is a dependency. Every dependency is something that can break, need an update, or leak a vulnerability. Over enough years, the compound interest on complexity is brutal.

A static site is almost boring by comparison. Files on a server. A browser requests them. They show up. Nothing between you and the user that has to be patched, rebooted, or babysat. That's the point.

We don't build this way to be purists. We build this way because it's cheaper, faster, safer, and it lets us do better work for the clients we care about. When the right answer is WordPress, we'll tell you. Most of the time, it isn't.