** Why Stacking Creates Lock-In
Article:
Why Stacking Creates Lock-In
There's a pattern I keep running into when helping teams untangle their software stacks. Someone adds a tool because it solves today's problem. A few months later, another tool gets layered on top to patch the gaps the first one left behind. Fast forward two years, and nobody can remove anything without breaking everything. That's the moment it clicks: stacking doesn't just add complexity — it creates lock-in.
The reason is simpler than most people think. Every new layer you stack depends on the layers beneath it. The layer below becomes a contract, and contracts are hard to break. When your authentication sits on top of a framework, which sits on top of a database driver, which sits on top of a specific runtime version, you're not building features anymore — you're building a chain of dependencies where each link holds the others in place. The more links, the harder it is to swap any single one out.
But here's what most discussions about stack creep miss: stacking creates lock-in not just technically, but cognitively. Teams forget why a layer exists in the first place. The original problem gets buried under so many workarounds that removing a layer feels like removing a load-bearing wall. People stop asking "do we still need this?" and start assuming "this is just how it works here." That assumption is the real lock-in — the technical debt is just the visible symptom.
I've seen this play out with build pipelines especially. A team adds a bundler plugin to handle a legacy asset. Six months later, three other tools depend on that plugin's output format. Nobody remembers the legacy asset was deprecated. The plugin stays because "the build breaks without it." That's stacking creating lock-in in its purest form: a solution outliving its problem, now defended by a web of dependencies nobody chose deliberately.
Why Stacking Creates Lock-In comes down to three mechanics worth naming:
- Dependency chains harden over time. Early on, layers are loose and swappable. Every integration, every shared config, every implicit assumption makes the chain stiffer.
- Sunk cost gets socialized. One person's decision becomes the team's constraint. Nobody wants to be the one who "broke the stack," so the layers stay.
- Removal requires understanding the whole. Adding a layer needs local knowledge. Removing one needs global knowledge — and global knowledge decays fast in busy teams.
So what's the way out? Not refusing to stack — that's unrealistic. The fix is deliberate friction: document why each layer exists, date it, and schedule reviews. If a layer can't justify itself against its original problem, it's a lock-in candidate. And when you do stack, prefer layers with clean seams — interfaces you can cut at without unraveling the rest.
The bottom line: stacking feels like progress because it's additive. But every addition quietly narrows your future options. Why stacking creates lock-in isn't a mystery — it's arithmetic. The more layers you pile up, the more your stack owns you instead of the other way around.
