We Fired 18 Plugins (and Nobody Got Hurt)

What happens when an agency that builds websites for clients finally rebuilds its own.

We've been building digital products for clients since 2010. WordPress sites. React apps. Mobile apps. E-commerce platforms. AI integrations. You name it, we've shipped it.

But our own website? It ran on WordPress. For years. With 18 plugins.

Security plugins. Caching plugins. Backup plugins. SEO plugins. Form plugins. Page builder plugins. Contact plugins. And a few we'd forgotten we even had.

Then we migrated. Next.js. Supabase. Vercel. Zero plugins. And the site is faster, cheaper, and easier to maintain.

Here's why we did it, what we lost, and what we gained.

---

The Plugin Problem

WordPress is powerful because of its ecosystem. Install a plugin, get a feature. Need caching? Install a caching plugin. Need backups? Install a backup plugin. Need better SEO? Install an SEO plugin.

The problem isn't any single plugin. It's the accumulation. Each one adds:

• Attack surface. More code, more dependencies, more things that can break or get exploited.
• Update fatigue. Plugins update. WordPress updates. PHP updates. You spend more time maintaining than building.
• Hidden complexity. You don't own the code. When something breaks, you're debugging someone else's black box.
• Performance tax. Even with caching, you're still loading a database, a theme, and a pile of plugin logic on every request.

We're not anti-WordPress. We still build WordPress sites for clients when it's the right fit. But for our own agency site—a relatively static marketing site with a blog, contact forms, and a few dynamic features—WordPress plus 18 plugins was overkill.

We were eating our own dog food, but the dog food had gotten stale.

---

What We Replaced

We rebuilt the site with:

• Next.js for the frontend. React, server components, static generation where it makes sense.
• Supabase for auth, database, and any dynamic data. Managed, scalable, no plugins.
• Vercel for hosting. Automatic deploys from Git. Edge functions if we need them.
• Markdown for blog posts. Stored in the repo. No database, no CMS. Just files.

The blog, the services pages, the about page, the contact form—all of it lives in code we control. When we want to change something, we change the code. No plugin settings. No database migrations. No mystery updates breaking things at 2 AM.

---

What We Fired

We didn't just remove WordPress. We removed 18 plugins that had accumulated over the years:

• Security suites (firewall, malware scanning, login hardening)
• Caching layers (page cache, object cache, CDN integration)
• Backup tools (database and file backups)
• SEO plugins (meta tags, sitemaps, schema)
• Form builders (contact forms, lead capture)
• Page builders (layout and design)

Some of these we replaced with purpose-built code. SEO is handled in our Next.js metadata and structured data. Forms go through our own API. Caching is handled by Vercel's edge network. Backups? The entire site is in Git. If we need to restore, we redeploy.

The rest we didn't need at all. We simplified the requirements and then built for those requirements—not for the generic WordPress use case.

---

Cost and Maintenance

Before migration:

• Hosting
• SSL (sometimes bundled, sometimes not)
• Premium security plugin
• Premium backup plugin
• Premium SEO plugin
• Time spent on plugin updates, compatibility checks, and occasional breakage

After migration:

• Vercel free tier (more than enough for our traffic)
• Supabase free tier
• SSL and CDN included
• Updates are "git push." No plugin dashboards. No compatibility surprises.

The real savings aren't just dollar amounts. They're in reduced cognitive load. We know exactly what our site does and how it works. When something breaks, we can debug it. When we want a new feature, we build it. No plugin hunting. No vendor lock-in. No surprise deprecations.

---

Sober Engineering, Applied to Ourselves

We talk a lot about sober engineering—using AI and modern tools as accelerants while keeping architectural rigor. The same philosophy applies to our own stack.

We didn't migrate because WordPress is bad. We migrated because our specific use case didn't need WordPress's flexibility. We needed speed, simplicity, and full ownership. Next.js and Supabase give us that.

If you're running a content-heavy site with multiple editors, complex workflows, or a lot of third-party integrations, WordPress might still be the right choice. But if you're a small team with a marketing site and a blog? Consider whether you need 18 plugins—or whether you need a lean stack you can fully understand and control.

---

The Bottom Line

We fired 18 plugins. Nobody got hurt. The site is faster. The bills are lower. The maintenance burden is lighter. And we're walking the walk: building with the kind of stack we recommend to clients who want clarity, performance, and control.

If you're thinking about migrating off WordPress—or simplifying any part of your stack—we're happy to help. We've done it for ourselves. We can do it for you.

---

Start a project with &Pixels → andpixels.com