You should be interested in building something that others don't want to replace as soon as you leave. That doesn't require predicting the future.
It should be obvious that people not caring what comes after them is not a good thing.
It should be obvious that people not caring what comes after them is not a good thing.
Write for your current requirements not some future state because people will say your work was subpar or overkill regardless because you are not around to defend your decisions and putting you down raises them up.
Things you learn after 25 years.
Things my interns learned in the first month as part of new hire training.
My quip above is to illustrate that in a dynamic and complex field its important we don't over index on experience.
> If you write something simple and basic someone will try to add their complexity.
Note that extending != rewriting.
The dev team going away for 3 months to rewrite is probably a bad idea, though. There are definitely good ways to rewrite and then not good ways.