Software that lasts
The industry is obsessed with scale. Can it handle a million users? Does it have microservices? Kubernetes? Auto-scaling?
After 25 years I think the better question is: will this still work in five?
Scale is a luxury problem
Most software never needs to handle a million requests. Most businesses never hit the point where database performance matters more than how fast you can ship a fix.
But every piece of software faces time. Dependencies break. Vulnerabilities show up. People leave. Requirements shift. The person who wrote it forgets why they wrote it that way.
The software that survives isn’t the software that scales. It’s the software that lasts.
What makes software durable
Boring technology. Rails is boring. Postgres is boring. Phoenix is getting there. Good. Boring tech has documentation, Stack Overflow answers, and battle-tested patterns. When something breaks at 3am, you can fix it. Five years from now you can still hire someone who knows it.
Few dependencies. Every library you add is a commitment. Every npm package is a potential security hole you’ll deal with for the life of the project. I’m not saying avoid libraries. I’m saying treat each one like what it is — a long-term relationship.
Clear boundaries. Microservices aren’t durability. They’re complexity with a marketing budget. What matters is clear separation of concerns. Modules that do one thing. Code that makes sense six months later. Elixir’s OTP does this well — you get boundaries without the operational nightmare.
Code that explains itself. Comments rot. Documentation lies. The code is the only source of truth. Clear names, obvious structure, no clever tricks. When I look at something I wrote five years ago, I shouldn’t need to reverse-engineer my own thinking.
The off-grid test
Living off-grid teaches you this. When your battery’s at 20% and it’s minus 40 outside, you appreciate systems that just work. No fuss, no cleverness, no single point of failure.
Software’s the same. The best code isn’t the code that impresses other developers. It’s the code that keeps running when everyone’s moved on.
Practically speaking
Choose proven tech unless someone’s paying you to take the risk. Write tests. Keep it simple — complexity is a maintenance tax you’ll pay forever. Document your decisions, not your implementation. Build for change, because the requirements will change.
Rails is 20 years old. Postgres is 30-something. They’re not going anywhere. The hot framework from six months ago? Check back in five years.
Scale when you need to. Build for durability first.