You clone a new repo, open the README, and they tell you the developer experience is highly optimized. Apparently, you just have to fire off one command for everything to magically spin up: make dev.
Oh, it spins up alright. Your laptop basically takes off like a jet engine.
Three minutes later, you have 15 containers spitting out logs. There’s a local orchestrator, three databases, a Kafka broker that no one really knows why it’s there, a reverse proxy, and a daemon eating 4GB of RAM just to watch and compile code in real-time. All of this just to center a sad div or add an endpoint that returns a JSON.
We’ve been sold a bill of goods with extreme DevEx. Sometime in the last few years, the industry decided that your local environment had to be an exact replica of the microservices hell running in production. We bought into the Big Tech hype and dragged their complexity right into our localhost, ignoring the main trap in all this: every tool you add is a layer of abstraction, and abstractions leak.
When the app blows up, you waste the entire morning trying to figure out if it’s an actual bug in your logic, a Docker volume that failed to sync permissions, or if the hot-reload just hung. And the worst part is that this complexity doesn’t make you faster—quite the opposite. The time you spend wrestling with your dev environment is time you aren’t writing code or iterating on your product. It’s a hidden cost that eats away at your productivity and your drive.
Take a hatchet to it and trim the fat
Developing should be a tight feedback loop: you write, you break, you fix. Anything that pulls you out of that deep work zone is noise, and noise must be eliminated ruthlessly.
The solution is to go back to boring and prune aggressively. If a service can be spun up bare-metal using the binary on your machine, do it. Don’t shove Node or PHP into a container just for local development unless strictly necessary. You also don’t need a Redis cluster running locally to test if a controller returns a 200 OK; an in-memory array or a temporary mock does the job perfectly.
Move away from endless config files to simple scripts that only spin up the main database, leaving the rest turned off by default. Fewer dependencies mean a smaller failure surface. Sometimes, the smartest technical decision you can make today isn’t adding another tool to your stack, but having the guts to delete three of them.