I happened to be full-timing in a camper at the time, and I found the inspiration for the concept came from my digital nomadic life, where I brought all of my things, and my structure with me, and it would fit and work everywhere I went. Unsurprisingly, I found myself thinking about my life, and the code I was writing, and I realized there were a lot of parallels.

I wanted my code to be nomadic, just like my own life.

The Nomadic Shift

The core idea behind the nomadic approach is to write your code so that it can run anywhere, on any platform. I wanted Siren to work just as well on WordPress as it would on a custom PHP service, or even a Laravel app down the road. To do that, I needed to create a separation between the business logic and the platform it runs on.

To do that, PHPNomad makes extensive use of the strategy pattern with a basic dependency injection system. This approach creates a layer that buffers the system from the integration.

As a result, PHPNomad ends up enforcing inversion of control. For example, if you built a WordPress plugin using PHPNomad, the plugin does not integrate into WordPress, WordPress integrates into the plugin. By creating this abstraction, I could make my codebase reusable and portable, able to shift between platforms like WordPress, Drupal, Joomla, or any PHP-based system. By switching out which integration is being used, you can migrate the majority of your system to something new with minimal effort.

This was a major turning point in how I approached development. Instead of thinking about each platform as its own isolated system, I started imagining the code itself as a traveler, adapting to whatever environment it was placed in.

After the recent drama with WordPress, I’m really glad I was thinking ahead. It brought me great comfort knowing that if push comes to shove, I can migrate Siren wherever I want without needing to completely start over. Don’t get me wrong, it’s still a lot of work, and I’d likely still need to support the plugin at the same time, but about 90% of the code would be able to come along for the ride.

Benefits Of Nomadic

When I set out to build PHPNomad, my primary goal was to ensure my approach kept my options open. Siren was built as a WordPress plugin, but behind the scenes, it’s actually a microservice architecture compiled into a single plugin. Because it was built using nomadic principles, if I ever want to transform Siren into a full-fledged SaaS, I can do that without rebuilding everything.

I can start by running Siren as a single service, much like it does now in WordPress. Then, as the system grows and scales, I can extract parts of the software into their own microservices. While that move isn’t necessarily trivial, it’s entirely doable because the code is already designed to work in isolated pieces.

I Want To Use It For Everything Now

Once I started building with this nomadic mindset, it became clear that this approach isn’t just about portability—it’s about the development experience. The more I used it, the more I realized how much smoother my workflow became. I don’t have to constantly switch my thinking from one platform to another. Whether I’m working on a WordPress plugin or a custom PHP service, everything flows in the same context.

The consistency is what I love the most. I’m not constantly shifting between different sets of tools or paradigms for every new project. It’s the same code, the same patterns, and the same structure, no matter what platform I’m working on. That reduced context switching makes everything faster and less mentally draining, and it’s why I want to use this approach in every project I take on now.

There’s always a ramp-up when I’m integrating PHPNomad with a new platform, and that’s a nontrivial amount of work, but I love working in the platform so much that I usually don’t mind going through the trouble.

Outsourcing Is Easier

This consistency has another really great benefit – it makes it a lot easier to outsource development in my agency.

Instead of having to find developers with deep platform-specific knowledge, I can hire a PHP developer who understands the nomadic framework. The learning curve for the platform becomes a lot more manageable, and once they get the hang of it, they can build anything for any client we’re working with.

It doesn’t matter if it’s a Laravel app, a custom service, or a WordPress plugin or all of the above – everyone who’s on the nomadic team can work across projects without needing to know a ton of domain knowledge of these platforms.

The nomadic approach doesn’t just make code flexible—it makes developers flexible too. I can take someone with a WordPress background and have them work on a Laravel project, with very little adjustment. That consistency in development flow has been a huge win for my team.

Potential Pitfalls

There are none. It’s perfect!

just kidding.

The nomadic approach isn’t without its challenges. One of the most common pitfalls I’ve run into—and I see others run into—is failing to think about how the code will function in other environments. For example, if your datastore relies on MySQL and you later want to switch to a RESTful API, some things might translate easily, but complex queries (like those using JOINs) don’t always work as smoothly.

Thinking nomadically definitely adds some extra complexity to some projects, and if it’s a really simple solution it might not be worth bothering with it. Is it worth building an entire custom datastore for a single WP_Query you’re running on a site that you know is never going to leave WordPress? Probably not.

It’s important to plan for flexibility from the start. But the good news is, once you get the hang of it, it becomes second nature. As PHPNomad continues to grow, many of these challenges are being handled with best practices and common patterns, making it easier to avoid these roadblocks.

A Mindset as Much as a Framework

What I’ve realized along the way is that the nomadic approach is a mindset as much as it is a method. You have to get into the habit of building code as if it’s not tied to any specific platform. It requires more upfront planning, but the long-term benefits are worth it. You future-proof your code, keep your development flow consistent, and have the freedom to adapt your systems to new environments with minimal effort.

If you’re hesitant about taking that first step, don’t be. It might feel daunting at first, but it’s a muscle you grow over time. Eventually, you’ll find yourself thinking in nomadic terms automatically. And once you do, it’ll change how you approach writing code forever.