What “built to last” actually costs
Durable software is not a feature you add at the end. It is a series of refusals made early, and a maintenance bill almost nobody quotes up front.
“Built to last” sounds like something you add to software — extra polish, a sturdier framework, a longer warranty. In practice it is the opposite. Durability is mostly subtraction: the dependencies you decline, the abstractions you refuse, and the clever shortcut you talk yourself out of.
Durability is mostly refusal
Every dependency you add is a small loan against the future — someone else's code you now have to track, update, and eventually replace. Every clever abstraction is a bet that the cleverness will still be legible to whoever maintains it in three years, possibly you, on a bad day. The software that lasts tends to be the software that said no early and often.
- No dependency we cannot maintain ourselves. If a library disappeared tomorrow, could we carry its weight? If not, we think twice before taking it on.
- No abstraction we cannot explain in a sentence. Indirection that needs a diagram to justify it is usually buying less than it costs.
- No feature we cannot support for years. Shipping something is the cheap part; keeping it working is the bill that arrives later.
The bill arrives later
The cost of durable software is paid up front, in the unglamorous currency of saying no. That is why it can look slow from the outside. We are not being precious — we are declining to take out loans we would rather not repay with interest, in the form of a 2 a.m. incident or a rewrite nobody budgeted for.
Most software does not rot because it was built badly. It rots because every easy yes was a loan against a future no one priced.
So when we say a product is built to last, we do not mean it will never change. We mean the changes will be ones we can actually make — calmly, without fear, years from now. That is the whole promise, and it is more expensive than it looks.