I think this is a great question to keep asking, but unfortunately I don't have a good answer. I pose it as, "How can we make 1000 year software?" My observation is that as the rate of change of software accelerates, the maintenance burden for applications accelerates because the environments that your programs run in changes more often. It's kind of like the core problem of big slow orgs (too much communication/alignment work) but encoded in software -- a macro version of Conway's Law [0].

Some quick ideas I've been brewing on...

## Product strategy ##

- Keep it simple and focused. Each line of code and each dependency is a maintenance burden.

- Building open source is not necessarily an antidote to this. Other devs might help develop but opening the floodgates to community dev can also introduce feature complexity that your app perhaps doesn't actually need.

- Minimize service dependencies. Only use services that are commodity (e.g. 3rd party SMTP provider but not GPT-3).

## Software stack ##

- Choose tools that have a big community and multiple corporate users funding them.

- Choose stacks that are established. I often fail here because I want to live on the bleeding edge, but there's a reason it's called that.

- Choose tools that are open source (one company dying will not kill it).

- Choose tools that are cross-platform (the complexity of making a change to the tooling because of the diversity of clients is actually a pro for you, it won't change quickly). Also you want your tools to do as much of the heavy lifting around platform compatibility as possible. An iOS app written today will not work in 4 years without changes. A web app almost certainly will.

- Use as few tools as possible.

- When in doubt, go with the lindy option [1].

[0]: https://en.wikipedia.org/wiki/Conway's_law [1]: https://en.wikipedia.org/wiki/Lindy_effect