Why Local Development Feels Heavier Every Year
Local development has become heavier not because systems are inherently complex, but because organizations adopt tooling as cultural practice rather than necessity.
Teams implement Docker, CI/CD pipelines, and elaborate build systems for projects that never required them. The justification was always the same: "It's what everyone does".
This is a cultural problem, not a technical one.
Companies optimize for perceived standards and industry practices without evaluating fit. A five-developer team building a small web application inherits the same infrastructure philosophy as Netflix or Uber. The weight compounds because tooling decisions are rarely questioned once made.
Where Tools Get Unjustified
Docker illustrates this pattern clearly. For solo developers, Docker introduces overhead through filesystem latency and excessive RAM usage.
Yet teams add it to projects where everyone uses the same operating system and there is no production parity concern. Teams that ditched Docker for local development found it was slowing them down more than helping.
The cognitive overhead of Docker requires developers to jump through containers and master the Docker CLI itself, creating drag on achieving actual goals.
For projects with single developers or small teams doing feature development, this overhead exceeds the benefit.
The same applies to NPM dependencies. Studies analyzing CommonJS packages found that 50.7% of dependencies are bloated and can be successfully removed while maintaining correct builds.
Across 92 packages examined, only one package had no bloated dependencies despite including 259 total dependencies. Projects accumulate packages for convenience without auditing what actually runs in production.
The JavaScript ecosystem includes many packages that provide functionality native to modern JavaScript for years, like is-string for type checking and hasown for property checks. These exist for legacy compatibility nobody needs anymore.
The CI/CD Question
CI/CD pipelines receive uncritical adoption across all project sizes. The industry narrative is that every project benefits. The reality is more nuanced. For small projects with short development times or no continuous support after release, CI/CD pipelines may not be worth the complexity cost. Small teams that update the codebase infrequently can find and fix bugs during development without continuous integration.
CI/CD serves clear purposes: catching integration issues across multiple developers, automating deployment verification, reducing manual error. Small solo projects gain little from these. The infrastructure investment to set up and maintain CI/CD pipelines exceeds the value for projects that deploy rarely or never reach production complexity.
Projects that will persist, that will have long-term maintenance, that will add team members — these benefit from CI/CD. But a prototype, a learning project, a tool built for personal use does not. The cultural assumption that CI/CD is mandatory for "professional" work obscures this distinction.
The Cost of Cargo Cult Infrastructure
Every tool adds surface area. Configuration files multiply. Documentation spreads across multiple ecosystems. New developers inherit systems designed for problems they do not have. A developer joining a project with Docker, npm bloat, and complex build tooling must understand all three before touching application code.
The pattern repeats: tooling persists long after justification fades. Removing tools feels risky. Something might depend on them. Undocumented interactions form. The sunk cost of maintenance exceeds the cost of adding new tools, so they accumulate.
Where the local setup required understanding five layers of abstraction before any work could begin. None of those layers was wrong in isolation. Collectively, they made simple tasks expensive. The developers did not move faster. They moved the same speed while paying a cognitive tax.
The Alternative: Justification-First Tooling
Projects should start minimal. Add tools when they solve concrete problems. Question whether the problem is real or perceived. A project with two developers on the same OS gains little to nothing from Docker. A project that deploys once per month gains little from CI/CD. A project with three dependencies does not need sophisticated dependency management.
This requires resisting cultural pressure. It requires saying no to tools everyone uses. It requires accepting that different projects have different needs. A small web application is not a microservices platform. A learning project is not production infrastructure.
The weight in local development comes from organizations adopting industry-standard infrastructure for non-standard problems.
Better development (and developers) comes from matching tools to actual constraints, not to organizational aspirations about scale that may never materialize.