Why I Replaced 120 WordPress Sites With a Single Tool

At one point, I was responsible for over 120 WordPress installations. Each one was a landing page or ordering funnel for a different marketing campaign. Each one had its own plugins, its own theme quirks, its own PHP version requirements. Each one was a security patch waiting to happen.

The maintenance burden was absurd. And the thing that bothered me most was that none of these sites needed WordPress.

The Real Problem

WordPress is a content management system. It's built for blogs, for sites where content changes frequently, where multiple editors collaborate, where you need a plugin ecosystem. These 120 sites were none of that. They were static marketing pages — a hero image, some copy, a call-to-action button, maybe a form. Once published, most of them never changed.

But someone, years ago, had decided WordPress was the standard. So every new campaign meant spinning up a new WordPress instance, configuring it, installing the same five plugins, building the page in a visual editor, and deploying it. A process that took roughly a week per landing page. Then multiply that by the ongoing cost: hosting, SSL certificates, security patches, plugin updates, database backups. For a page that was essentially static HTML.

I started asking: what if we stopped pretending these were websites?

The Solution: A Page Builder That Outputs Static Files

I built a page builder using Grapes.js, an open-source web builder framework. The tool let marketing integrators design pages visually — drag and drop components, customize styles, add forms — and then export the result as static HTML, CSS, and JavaScript. No server-side rendering. No database. No PHP.

The static output got deployed to S3 and served through CloudFront. A landing page that previously required a WordPress server, a MySQL database, and ongoing maintenance now cost fractions of a cent per month to host and served in milliseconds from edge locations worldwide.

The architecture was deliberately simple:

Page Builder (Grapes.js) → Static HTML/CSS/JS → S3 → CloudFront → End User

No moving parts in production. Nothing to patch. Nothing to hack.

Training 20+ Integrators

A tool is worthless if nobody uses it. The previous WordPress workflow was slow, but people knew it. Introducing a new tool meant convincing integrators to abandon something familiar.

I focused on two things: speed and guardrails.

Speed was the easy sell. Building a landing page in the new tool took about two hours instead of a week. Once people saw that, adoption wasn't a hard conversation.

Guardrails took more effort. I built an SCSS component library for the page builder — a Campaign Manager resource kit that gave integrators pre-styled, reusable blocks. Headers, pricing tables, testimonial sections, CTA buttons — all following brand guidelines. This served two purposes: it made pages look consistent, and it kept integrators from writing custom CSS that would break across browsers.

The SCSS library was versioned and documented. When the design team updated brand colors or typography, I updated the library once, and every new page automatically picked up the changes. Compare that to updating 120 WordPress themes individually.

A/B Testing Without a Platform

One feature I'm particularly satisfied with: built-in A/B testing that required no third-party service.

The approach used Lambda@Edge (CloudFront's edge compute) to assign users to test variants. When a request came in, the function checked for an existing variant cookie. If none existed, it generated a consistent assignment using a hash of a client fingerprint combined with a random seed. The user always saw the same variant on return visits, but the distribution across the population was random.

Request → Lambda@Edge → Check cookie → Assign variant (or reuse existing) → Serve variant

No analytics platform required for the split. We tracked conversions separately. The elegance was in the simplicity: the A/B logic lived at the CDN edge, added negligible latency, and required zero infrastructure beyond what we already had.

The Results

I want to frame these as what they actually were — problems that went away.

The security problem went away. No more WordPress core updates. No more plugin vulnerabilities. No more panicked patching when a zero-day hit a popular plugin. Static files on S3 have an attack surface of approximately zero.

The cost problem went away. Server costs dropped by roughly 90%. We went from dozens of hosted WordPress instances to a single S3 bucket and a CloudFront distribution. The monthly bill became negligible.

The speed problem went away. Integrators shipped campaigns in hours instead of days. The page builder enforced consistency, so QA reviews got faster too. And the pages themselves loaded faster — static files from a CDN versus a WordPress site making database queries on every request.

The scaling problem went away. A viral campaign that suddenly gets millions of hits? CloudFront handles that. No capacity planning, no server upgrades, no caching layer to configure.

When to Build vs. Buy

This project taught me something about the build-vs-buy decision that I think gets overlooked: the right answer depends on what you're actually doing, not what you think you're doing.

We thought we were running 120 websites. We were actually publishing 120 static pages. Once we reframed the problem, WordPress was obviously the wrong tool. But it took stepping back and questioning the assumption — "we need a CMS" — to see it.

I've seen the same pattern elsewhere. Teams running Kubernetes for three services. Companies paying for enterprise monitoring when Prometheus and Grafana would do. The tool is rarely the problem. The mismatch between the tool and the actual need is.

If I had to distill the lesson: before you optimize a process, ask whether the process should exist at all. We didn't optimize our WordPress workflow. We eliminated it. And that made all the difference.

Building a custom tool was the right call here because the problem was narrow and well-defined. We didn't need a general-purpose CMS. We needed a machine that turns marketing briefs into static pages, fast. That's a specific enough problem that a focused tool will always beat a general one.

But I've also been on projects where building custom was the wrong call. The difference is scope. If your problem is "we need a blog," install WordPress. If your problem is "we need to publish 120 static pages with A/B testing and we're spending a week per page," build the thing.

Know your problem. Then pick the tool that fits.