It's actually a lot easier to maintain and extend something over a long lifespan if it doesn't have tons of dependencies from many different sources evolving in

It's actually a lot easier to maintain and extend something over a long lifespan if it doesn't have tons of dependencies from many different sources evolving in different directions at different velocities. In a long-lived application, early team members will need to learn the new tech and later team members will need training in the old ways to work on your now-archaic tech stack (that you couldn't upgrade because of version incompatibilities). They'll also need custom-built dev systems that come with the project (because some of the tools are no longer available in those versions or at all). You won't be able to use new tools without first backporting them. You may have to deal with potential security issues in code that is no longer supported even though you don't even need that code, because it's there in the dependencies. In fact, in some cases the use of lots of dependencies might actually be better for quick prototyping (because they let you do so much with so little development) that you don't have to maintain and extend than for long-term projects. It's a tradeoff. Either way has benefits and drawbacks.