# What survives when every tool changes > Frameworks, vendors, and models all have a shelf life measured in quarters. The work that compounds is the architecture underneath - the part designed to outlive the implementations that happen to express it today. - Author: Mohit Rane (Founding Architect) - Published: 2026-04-08 - Category: Future Systems - Tags: architecture, durability, abstraction, tooling - Canonical: https://mohitrane.com/writing/what-survives-when-every-tool-changes/ --- If you have built systems for any length of time, you have lived through the funerals. The framework that was going to be the standard forever. The vendor that was unquestionably the right choice. The model that everyone built around. Each felt permanent while it lasted and disposable the moment its successor arrived. The half-life of a tool is short and getting shorter, and anyone planning otherwise is planning for a world that has never existed. This is usually told as a cautionary tale about chasing trends. I think that framing is too defeatist. The lesson is not that nothing lasts. It is that you have to be deliberate about *what* you intend to last, because the things that survive and the things that get replaced are not the same things - and confusing the two is the most expensive mistake in systems work. ## Two layers, two lifespans Every system you build has two layers running through it, even when they are tangled together in the same code. There is the **durable layer**: the structure of the problem, the boundaries between concerns, the contracts between components, the invariants that have to hold regardless of how they are enforced, the model of what the system is actually for. This layer changes slowly because it tracks the shape of reality, not the shape of this year's tooling. There is the **disposable layer**: the specific framework, the specific vendor, the specific model, the specific library that happens to implement the durable structure right now. This layer changes fast because it tracks the market, and the market is not loyal to you. The mistake is not using disposable tools - you have no choice, every implementation is disposable eventually. The mistake is letting the disposable layer dictate the durable one. When your architecture is shaped by the quirks of a particular vendor's API, you have welded a thirty-year structure to a three-year component, and you will pay for the mismatch when the component is retired and the structure has to be torn out with it. > Durable architecture is the part of the system you could explain to a competent engineer who has never heard of any of the tools you used. If the explanation falls apart without naming a vendor, you have described an implementation, not an architecture. ## How to tell the layers apart, in advance The hard part is that the two layers do not announce themselves. In the moment, the vendor's recommended pattern and your system's real structure look identical, because you adopted the pattern to express the structure. Telling them apart requires a deliberate test, applied before you commit. The test I use is the **replacement test**: for each significant design choice, ask what would have to change if the underlying tool were swapped for a competitor. If the answer is "an adapter and some configuration," the choice lives in the disposable layer and the durable layer is properly insulated. If the answer is "the whole data model and half the application logic," the disposable layer has leaked into the durable one, and you have a future migration that will be sold internally as a rewrite. This is the discipline behind the [system-of-systems framework](/frameworks/system-of-systems-framework): designing each system so that its durable structure is expressed through, but never dependent on, the disposable tools currently implementing it. The boundaries are drawn so that tools can be swapped at the seams without the structure noticing. ## Durability is a design choice, not a property of the tool Here is the part that is easy to miss. No tool is inherently durable. Durability is not something you find by picking the right vendor - there is no vendor whose product will outlive your system, and betting on one is just choosing which funeral you will attend. Durability is something you *design*, by deciding which commitments belong to the structure and refusing to let any single tool own them. This means accepting a real cost. The insulating layer - the adapters, the abstractions, the contracts that keep tools at arm's length - is overhead. It is slower to build than wiring directly to the vendor's SDK, and in the first year it looks like wasted effort. It pays off only when the first tool dies, and then it pays off completely, because the death is a swap instead of a rewrite. ## The closing thought The systems that last are not the ones built on the best tools. They are the ones built so that the tools were never the point. When every framework you used has been deprecated, every vendor renegotiated, and every model superseded, what remains is the structure - the boundaries, the contracts, the model of the problem - and whether that structure was designed to stand on its own or merely to host whatever was popular when you started. Build for the funeral you cannot see coming. The tools will all attend it. The architecture is the only guest you get to keep.