When WordPress Stopped Making Sense

The setup was straightforward enough. WordPress handled the backend, I built a custom plugin for the API logic, and React handled the frontend. At first, it worked. Actually, it worked pretty well. I had custom endpoints, user roles, authentication, data coming in and out of WordPress, and a frontend that did not really care what was happening behind the scenes.

Then the project started growing.

WordPress Was Doing the Job

I should probably say this before Laravel people start sharpening their knives 😂. WordPress was not the problem. It did what I asked it to do.

The custom plugin gave me control over the parts I needed. I could create REST API endpoints, validate requests, work with users and roles, and add my own application logic without touching WordPress core. That experience actually helped me understand backend development better.

Once you stop relying entirely on plugins and start writing your own endpoints, you begin seeing WordPress differently. It stops being just a CMS with an admin dashboard and starts looking like a system you can extend quite far.

And I extended it. Quite far Tbh.

Then I Started Asking It to Do More

The more features I added, the more time I spent inside that custom plugin. Authentication logic lived there. Permissions lived there. Different user roles needed different behaviour. There were uploads, orders, payments, invitations and other application-specific features.

At some point, I realised I was doing quite a lot of work just to convince WordPress that it was an application backend. WordPress was cooperating, to be fair. But I started wondering whether I was using the right tool or simply getting very good at making the current one behave.

And... That was really the turning point.

Laravel Felt More Deliberate

When I started working seriously with Laravel, a lot of things I had been manually organising suddenly had a proper place. Routes were routes. Controllers handled requests. Models represented my data. Middleware could deal with access rules. Validation had a clear structure. Database migrations gave me a proper history of how the database changed.

The difference was that Laravel seemed to expect me to build an application. I was no longer extending a content management system until it looked like one, uh-huh.

That distinction started to matter more as the projects I wanted to build became less about publishing content and more about application logic.

I Also Wanted to Understand What Was Happening

There was another reason for the move. I wanted to become better at backend development.

With WordPress, I already knew many of the shortcuts. There is usually a hook, a function, a plugin or an existing WordPress way of doing something. That is incredibly useful when the goal is to ship something quickly.

But I wanted to understand more of the structure underneath the things I was building. Why should this request go through middleware? Why should this logic live in a service instead of a controller? How should these database tables relate to each other? What should happen when a request fails validation? How should authentication work when the frontend is separate from the backend?

Laravel forced me to think about those questions more often because it made the answer clearer. Other times because I had broken something and had no choice. Both were useful.

React Wasn't the Reason Either

Moving away from the headless WordPress setup did not really have anything to do with React. A Laravel backend can still serve a completely separate React frontend. Or I can keep things inside Laravel and use Blade when a separate frontend would only create more work.

That flexibility started making more sense to me. Not every project needs to be headless. Not every project needs a JavaScript frontend. And not every project needs Blade either.

I became more interested in choosing the architecture based on the project instead of deciding the stack first and forcing everything into it.

Where WordPress Still Makes Sense

I haven't suddenly developed an allergy to WordPress. There are projects where I would still choose it without thinking twice.

A basic website, company site, blog, publication or content-heavy project can make perfect sense in WordPress. The editor experience is basic, clients understand it and there is an enormous ecosystem around it. WooCommerce also solves a lot of ecommerce problems that I would not necessarily want to rebuild from scratch for every client.

Laravel does not replace WordPress for me. It simply gives me another tool for a different kind of problem.

The Move Was Really About What I Wanted to Build

The projects I am increasingly interested in involve more custom behaviour. Dashboards. Different types of users. APIs. Permissions. Business rules. Background processes. Integrations. Things where the backend is not simply storing content for someone to publish later.

For that kind of work, Laravel feels more natural to me.

Moving to Laravel was not me discovering that WordPress was bad. It was me getting clearer about the kind of developer I wanted to become and the kind of applications I wanted to build.

Sometimes changing tools is not really about the tool at all. Sometimes your requirements just outgrow the reason you chose it in the first place.