Why I’m building my own solution: A story of Next.js, WordPress, and two custom plugins

I’ve got my backend in WordPress, my frontend built with Next.js, and the frontend hosted on Netlify. A pretty standard setup for many developers. But of course, I couldn’t just stick with standard solutions. I’m the type who loves having control over every detail—especially when it comes to security and control over my code.

So, what do you do when you want a lightning-fast website with solid security? You build your own plugins, of course!

Two custom-built plugins — Why?

You might be thinking, aren’t there already plugins for exactly the two tasks I set out to solve?

Yes, there are. But they often come with costs, or they include lots of extra features you don’t need. Or, even worse, they provide 90% of what you need, and then you have to compromise. And I’m just not into that. I want solutions that fit my clients’ needs precisely. So, I developed two plugins focused on quick implementation and tailored functionality—no fuss, just results.

Plugin #1: Turn up the security

Security is essential in any web solution. With my first plugin, I’ve added a layer of security through header-based authentication for the WordPress API. This means only those with the correct access keys can reach backend data — pretty reassuring, right?

Plugin #2: Control your own builds

I love control—including over when Netlify builds a new version of my frontend. With my second plugin, I now have exactly that ability. I decide when Netlify generates a new build. No automatic builds without my approval—everything happens on my terms!

Here’s why this matters: Frequent builds can quickly become costly, especially if you update your content often. Every time Netlify builds a new version of your frontend, it uses your included “build minutes.” For small projects, this may not be an issue, but if you’re constantly triggering new builds—say, every time you update a blog post or change a small detail—it can add up.

But it doesn’t stop there. Frequent builds aren’t just a financial burden—they can also negatively impact the environment. Each time we avoid pinging servers unnecessarily and only build when it’s truly needed, we reduce energy consumption. And less energy use means less CO₂ emission. So beyond saving resources and keeping costs down, we’re also helping protect the environment by not overloading servers with unnecessary builds.

With my plugin, I’m not only ensuring full control over build timing—I’m also helping make my projects, and the world, a little greener. 🌍

Why not just keep everything in WordPress?

Let me make it crystal clear: You get an insanely fast website by having the frontend in Next.js. It’s ridiculous how well it performs. Shall we take a look at how Lighthouse scores this website? Spoiler alert: It’s fast.

Sorry for the confetti on the screenshot—it happens when you hit 100% on all metrics 🤷🏻‍♂️

Security is also top-notch. Good luck hacking a static site! The backend may still be vulnerable to attacks, but the frontend is static. As long as you don’t build a new frontend, your backend can be completely down, and your visitors will never notice.

Why I develop my own plugins

Of course, I could use existing plugins, but there’s something satisfying about knowing that the code running on my clients’ websites is built precisely for their needs. It’s fast, it’s secure, and I know exactly how it works.

So, when I work on my projects, it’s not just about building a website. It’s about providing my clients with solutions that perform at their best—without compromising on speed or security.

Thanks for reading!