I built a lot of WordPress websites early in my freelance career.

WordPress itself was rarely the hardest part. The challenge was what happened after the site was finished and I handed it to the client. As too often I found myself giving clients instructions for a collection of plugins, explaining why one screen behaved differently from another, documenting workarounds, and teaching them which settings they should—and absolutely should not—touch.

Years later, I’ve started working seriously with WordPress again. This time I’m approaching the problem differently.

Instead of asking “Which plugin can get me closest to what the client needs?”, I’m increasingly asking: “What would this look like if it were built specifically for them?” That small change has completely altered how I build WordPress sites.

The Plugin Problem

The WordPress ecosystem is one of its greatest strengths. If you need a gallery, contact form, page builder, SEO tool, carousel, custom fields, or nearly anything else, somebody has probably built it.

The problem isn’t that finding a plugin isn’t difficult. But determining which plugin is appropriate for a particular project can be because you spend time compare features, documentation, reviews, compatibility, update history, pricing models, and how much additional functionality comes bundled with the one feature you actually need. Sometimes you find something close but close is often where the trouble starts.

Maybe the plugin handles nine of the ten requirements. You work around the tenth with CSS. Another plugin fills a different gap. Some custom PHP connects the two. Then another requirement appears and another plugin enters the stack and before long, a relatively straightforward client requirement has become a collection of third-party abstractions that all have to coexist.

And then you have to explain it to the person who actually owns the website.

A content management system isn’t really easier to manage if the client has to understand how a collection of plugins happens to fit together.

The Cost of “Close Enough”

You can spend significant time researching a solution, implement the best option you can find, train the client, and deliver the site. Six months later, you discover something that would have served them better.

That’s normal in technology, of course. We make decisions with the tools and information available at the time. But when you’re building for clients, it’s difficult not to look backward.

You begin seeing the compromises in previous projects: the plugin that required too many steps, the administration screen that exposed far more options than the client needed, or the workaround that made perfect sense technically but was awkward for the person actually maintaining the site.

Coming back to WordPress gave me an opportunity to reconsider that entire approach.

What If I Just Built the Missing Piece?

Modern AI-assisted development changed the economics of that decision for me.

Previously, building a custom WordPress plugin for a relatively small requirement could be difficult to justify. Even if the underlying functionality wasn’t particularly complicated, there was setup, boilerplate, WordPress API research, editor integration, validation, and all of the other work surrounding the feature itself.

Installing an existing plugin was usually faster but now AI has significantly reduced that startup cost.

Today, I can describe the component I need, use AI to help establish the initial structure, and then work directly with that code. Instead of spending the first part of the task reconstructing WordPress boilerplate from documentation, I can start much closer to the actual problem I’m trying to solve. I review it, understand it, test it, change it, integrate it with the rest of the site, and continue refining it until the component behaves the way I want.

The difference is that creating something purpose-built can now take surprisingly close to the amount of time I might otherwise spend researching, installing, configuring, styling, overriding, and connecting several general-purpose plugins.

And at the end, the client get’s exactly what they paid for with no need to learn any robust tooling or configuration.

Building for the Person Using It

That’s where this approach becomes more than a development convenience.

If a client needs three options, I can give them three options. Not thirty-seven options with documentation explaining which three matter.

If a page needs a specialized hero, I can create a comfortable interface containing exactly the fields required to construct that hero.

If case studies need an explicit order, I can provide an ordering field rather than asking the client to manipulate publication dates or remember some convention invented to satisfy another plugin.

The administration experience can reflect the client’s mental model of the website, rather than the architecture I happened to use to build it.

That’s a surprisingly important distinction because good content management shouldn’t require the person managing the content to think like the developer.

Components Instead of Pages

That thinking has also changed how I structure WordPress itself.

Rather than treating every page as a unique collection of markup, I’m building reusable components for recurring concepts so that the client works with meaningful pieces of their website instead of recreating layout conventions manually.

That gives me consistency without taking control away from the editor.

It also makes the site easier to evolve. When a component changes, I can improve the component rather than hunting through individual pages for slightly different versions of the same markup.

In that sense, I’m applying many of the same architectural principles I use when building larger applications: define responsibilities, establish clear interfaces, reuse behavior intentionally, and keep implementation details behind boundaries that make sense to the people consuming them.

Bringing Angular Into WordPress

I also don’t think WordPress has to solve every problem by itself.

For content-heavy portions of a site, server-rendered WordPress markup is often exactly what I want. It’s simple, accessible to search engines, and easy to manage but some interactions genuinely behave more like applications. For those, I’ve begun integrating Angular components into WordPress where the additional behavior is justified.

Forms are a good example. A contact form may need validation, asynchronous submission, spam protection, loading and success states, and other interactive behavior. Angular gives me a structured way to implement that functionality while WordPress continues handling the surrounding content and page lifecycle.

I’ve taken a similar approach to other dynamic elements: let WordPress own the content, and let the application layer enhance the pieces that benefit from richer behavior.

Importantly, I don’t want that enhancement to make meaningful content invisible to search engines or dependent on JavaScript just to exist so I’ve been exploring patterns where content remains present in the server-rendered markup while Angular uses directives and components to progressively add behavior around it.

The result isn’t really a “WordPress site with Angular bolted onto it.” It’s a system where each technology gets responsibility for the things it does well.

Coming Back to WordPress

What’s interesting to me is that I’ve ended up back at WordPress without really returning to the way I used to build WordPress sites in that the platform is familiar, but my approach is much closer to application development now.

I build small plugins with focused responsibilities. I create controls around the concepts editors actually need. I use reusable components instead of repeating page structures. I introduce Angular selectively when richer client-side behavior makes sense. And I use AI to shorten the distance between an idea and the first working implementation.

The result is a WordPress site with fewer compromises and less knowledge required from the person maintaining it and that’s ultimately the part I care about.

The client should be able to open their website, recognize what they want to change, change it, and move on.

If I’ve done the architecture well, most of the complexity should belong to me—not them.