I first learned to code using GUI-based tools on Windows. This included tools like TortoiseSVN for version control and WAMP to run a local an Apache/MySQL/PHP stack. It was a great introduction to programming, but didn’t prepare me for the real world.
Why? Because production wasn’t Windows. It was terminal-only Ubuntu.
That meant I was coding for one stack—my local stack—while deploying to something entirely different. Bugs were inevitable. I’d build against one PHP or MySQL version locally, only to deploy to something wildly different in production. And the results? Frustrating errors. Missed deadlines. Blame ping-pong between devs.
Now add teammates using MAMP, XAMPP, or cobbled-together local setups. Mix in clients with different web hosts, different configurations, different assumptions. You get chaos.
I wasted far too much time fixing issues that came down to one simple truth:
Inconsistent environments kill velocity.
Varying Vagrant Vagrants
The turning point came when a colleague introduced me to Vagrant. Later, Jeremy Felt introduced me to Varying Vagrant Vagrants (VVV), which automated WordPress dev environments using Vagrant and Bash.
For the first time, we could spin up isolated, fully consistent development environments—regardless of whether we were on macOS, Linux, or Windows.
I even went so far as to port the configuration to use Windows-native Hyper-V instead of VirtualBox. That experience led me deep into virtualization and earned me a role as a tech reviewer on a Hyper-V security book.
But more importantly: VVV solved the problem. My local environment matched production as closely as possible – same PHP version, same web server, same configuration. It just worked.
Back when I was deep in WordPress development, VVV was a lifesaver.
Evolving the Enterprise
Over the years, I’ve seen this same problem surface at startups, agencies, and enterprises alike. Developers use one OS, production uses another. Local builds are on ARM, prod runs on x86. Python projects can’t agree on Pip vs Pipx vs Anaconda vs Poetry.
The specifics change, but the problem remains:
When environments don’t match, things break.
We shouldn’t still be fighting this in 2025.
I’ve been solving this problem across multiple industries for over a decade. Building development environments that mirror production regardless of where things are deployed (AWS, GCP, bare metal, local VMs, etc) should be the default.
What’s Next: A Kit for Makers
As I mentioned last week, I’m packaging up my personal solution into something others can use. Think of it like VVV, but modernized:
- Built for any tech stack, not just WordPress.
- Designed to deploy anywhere—Kubernetes, cloud VMs, or bare metal.
- Built for solo developers and small teams who don’t have dedicated SREs.
I’m calling it a DIY Infrastructure Kit, and I’m building it in the open under my new label: Displace Technologies.
If you’ve ever lost hours debugging production issues that only exist because “it works on my machine,” this is for you.
Follow Along
You’ll be able to track progress:
- Right here on this blog
- On the Displace Technologies site (coming soon)
- On Twitter/X and Mastodon
If you’re tired of dev/prod drift and want infrastructure you can trust—follow along. I’m building this for you.