Five years ago I was building WordPress websites for clients. The kind of work where you install a theme, build a child theme on top of it, write custom PHP for features the theme never imagined, register post types for every content model the client needs, and wire everything together with hooks and filters until it actually does what the client asked for.

That was the job. Not dabbling. Full time. Real projects. Real deadlines.

Today I write Node.js APIs, React dashboards, Next.js applications, and Vue.js interfaces. WordPress is still in the stack on most projects. But the stack is bigger now.

This is the honest story of how that happened. Not a tutorial. Not a career advice post. Just what actually occurred.

What building WordPress websites actually taught me

Before anything else I want to be clear about what WordPress website development actually involves because the internet has a habit of dismissing it.

When I was building recruitment and staffing platforms on WordPress I was writing custom PHP classes. Registering custom post types and taxonomies. Building complex meta box systems for managing job listings and candidate profiles. Writing hooks and filters to modify WordPress core behavior without touching core files. Building custom REST API endpoints for frontend JavaScript to consume. Handling user roles and capabilities so recruiters saw different interfaces than candidates.

That is real software development. It taught me how a large PHP application is structured. It taught me to write code that other developers could extend without breaking. It taught me to think about security because WordPress has strict standards and gets you in the habit of sanitizing everything that comes in and escaping everything that goes out.

It also taught me something most tutorials skip: how to read someone else's code and understand a system you did not build. WordPress core is millions of lines of PHP written over twenty years by thousands of contributors. Learning to navigate that codebase, understand its patterns, and work with it rather than against it is a genuinely transferable skill.

I did not know at the time how much all of this would matter later.

The first project that pushed beyond WordPress

I was working on a staffing platform. WordPress was handling the content, the job listings, the user profiles, the admin dashboard. But the client needed automation. Resume parsing. Third party CRM sync. Automated email sequences triggered by candidate status changes. Workflow automation that ran on schedules.

Forcing this into WordPress was technically possible. WordPress has cron. WordPress has hooks you can fire on status changes. But the more I thought about it the more it felt like the wrong tool for the job. WordPress is designed around content management and web pages. What the client needed was a background processing system.

So we built a separate Node.js service alongside WordPress. WordPress remained the content layer. Node.js handled the automation layer. They communicated over REST API calls.

I had to learn Node.js properly for this. Not just reading tutorials. Actually building something in production that real people depended on.

The Node.js learning curve was not what I expected

I assumed the hard part would be JavaScript. I had been writing JavaScript inside WordPress for years. jQuery interactions. Block editor components. Admin page scripts. JavaScript was not new to me.

The hard part was the runtime model.

In WordPress PHP handles one request at a time in isolation. You write code that runs top to bottom. When it finishes the process ends. The next request starts fresh.

Node.js runs continuously. It handles multiple requests concurrently through an event loop. If you write blocking synchronous code you freeze the entire server not just one request. Every file read, every database query, every external API call needs to be async or you are doing it wrong.

My first week of Node.js code was full of synchronous operations that worked fine in isolation and would have been a disaster under any real load. I was writing PHP that happened to use JavaScript syntax.

It took about three weeks of real project work before the async model genuinely clicked. Before I stopped fighting it and started working with it. The moment it clicked it felt obvious in retrospect the way most things do once you understand them.

Building WordPress websites had given me something I did not realize

When I started building Express.js APIs I naturally wrote validation on every input. I checked that the authenticated user had permission to perform each action before performing it. I treated every piece of incoming data as potentially malicious until proven otherwise.

My colleagues on the project who came from other backgrounds did not have this habit by default. They would write an API endpoint that accepted whatever was sent and trusted it.

WordPress had trained me so thoroughly in defensive coding that I did it automatically without thinking about it. Sanitize inputs. Escape outputs. Check capabilities. Never trust user supplied data.

In the WordPress plugin ecosystem these practices are enforced. The Plugin Review Team will reject your submission if you violate them. You internalize them because you have to.

In Node.js nothing enforces them. You can ship an insecure API and it will run fine. Until it does not.

The discipline I brought from WordPress website development into Node.js made my APIs meaningfully more secure than they would have been otherwise. That was the first time I understood that WordPress development was not a limitation I was moving beyond. It was a foundation I was building on.

Then a dashboard needed React

The staffing platform automation was running on Node.js. WordPress was handling the content. But the client needed a proper admin dashboard. Not WordPress admin. A custom interface showing real time data from the automation system, candidate pipeline stages, recruiter performance metrics, integration status.

WordPress admin was not the right tool for this. We needed something more interactive and more tailored.

React was the decision.

I had written React inside the Gutenberg block editor. Enough to understand components and props and the basic rendering model. But building a full React application with its own routing, state management, and API layer was different.

The first thing that confused me was that React has strong opinions and punishes you for working against them. Coming from WordPress where you can hook into almost anything and modify almost any behavior, React initially felt rigid.

State flows one direction. Data goes down through props. Events go up through callbacks. You do not reach into a component from outside and change it. You change the state that drives it and React re-renders it automatically.

Once I stopped fighting this and accepted it as a design decision rather than a limitation something shifted. The rigidity is the point. It makes large applications easier to reason about because you always know where data comes from and how it changes.

WordPress is maximally extensible. Any plugin can modify any behavior. This is incredibly powerful and also the source of extraordinary debugging complexity when things go wrong.

React trades extensibility for predictability. Different tradeoff. Different use case. Neither is universally better.

Vue.js through a different project

Not every client chose React. A different project had an existing frontend codebase in Vue.js. New features needed to be built on top of it. I learned Vue.js on that project while it was running in production.

Vue.js after React is genuinely pleasant. The template syntax looks like HTML with some extra attributes. The component structure has a clear organization. The reactivity system works more automatically than React's manual dependency tracking.

Vue.js also felt conceptually closer to WordPress templating than React did. In WordPress PHP templates you write HTML and embed PHP expressions inside it. In Vue templates you write HTML and embed Vue directives inside it. The mental distance is smaller than React's JSX which feels more like writing JavaScript that outputs HTML.

For teams coming from HTML-first or PHP-first backgrounds Vue.js has a lower entry barrier. For larger teams with complex state requirements React's ecosystem is deeper and more established.

Knowing both made me more useful across more types of projects. That was the practical outcome.

Next.js felt like something I had already understood

Next.js came into the picture on a project that needed both great SEO and a rich interactive frontend. Pure client side React would hurt search performance. Pure server side WordPress would not give the interactivity we needed.

Next.js was the answer.

What surprised me was how much my WordPress background helped with Next.js specifically.

WordPress developers understand server side rendering instinctively because WordPress has always rendered pages on the server. The server generates HTML. The browser receives it and displays it. Search engines can crawl it because the content is in the HTML not injected by client side JavaScript.

Many React developers who came from client side rendering backgrounds struggle with Next.js because thinking about what renders on the server versus the client requires a mental model they never needed before.

For me it was familiar territory in a new form. The server renders something meaningful. The client receives it and makes it interactive. This is a more sophisticated version of what WordPress has been doing since the beginning.

Next.js also forced me to make explicit decisions about data fetching that WordPress makes for you automatically. Does this data come at build time. Does it come at request time. Does it come from the client after page load. WordPress decides this based on its own architecture. Next.js requires you to decide deliberately.

Making those decisions explicitly made me think more carefully about performance than I ever had when WordPress was handling it automatically. Discomfort that became a useful skill.

What the full journey changed

The biggest shift was not learning new syntax or new frameworks. It was learning to think about systems rather than just applications.

WordPress is a monolith. The database, the business logic, the templating, the admin interface all live together. This is a strength for many use cases. It is also a constraint on the kinds of architectures you can build.

Working with Node.js as a separate service alongside WordPress, feeding data to React and Vue.js frontends, building Next.js applications that treat WordPress as a headless CMS exposed me to thinking about systems as separate concerns that communicate over APIs.

That thinking changed my WordPress work too. I started designing WordPress plugins to expose clean REST API endpoints rather than assuming WordPress templates would always consume the data. I started thinking about WordPress as a data layer rather than a complete application. That is a more modern and more flexible way to build with WordPress.

I would not have gotten there without the broader journey.

Where things stand now

I still build WordPress systems. Custom plugins with clean architecture. REST API extensions. Block editor components. Headless WordPress feeding modern frontends.

I also build Node.js APIs. React dashboards and applications. Next.js server rendered sites. Vue.js interfaces.

These are not competing skills pulling in different directions. They are complementary skills that inform each other.

WordPress taught me to think about security, extensibility, and writing code that survives contact with the real world.

Node.js taught me to think about async systems and API design.

React and Vue.js taught me to think about state as the source of truth for everything a user sees.

Next.js taught me to think carefully about rendering and performance as deliberate architectural decisions.

Building WordPress websites for clients taught me to think about the person using the thing I am building and what they actually need. That is the skill that travels furthest across every stack.

The journey was not planned. It was a series of projects that each needed something slightly beyond what I already knew. I said yes each time. I figured it out each time.

That pattern has not changed. The stack has just gotten bigger.