Software projects are development projects, not constructions projects. They are similar to the engineer developing the blueprint for a new machine, not similar to the mechanic assembling it.
It's new projects that are hard and often have disastrous failures or cost overruns. I don't think software is unique in that regard. The Berlin Brandenburg Airport [1] and the new SF Bay Bridge [2] are cases in point. The latter included serious concerns about the integrity of the bolts that secure the East end of the suspension cables to its pier.
[1] https://en.wikipedia.org/wiki/Berlin_Brandenburg_Airport#Ove...
[2] https://www.wnyc.org/story/316201-brief-history-64-billion-b...
We could achieve such a setup by giving software a lifetime upfront and reimplement it after.
At the end of your several years, your stack will be “outdated,” so you will need to exercise discipline to resist the pressure to keep up with the trends.
I like your lifetime idea, though I foresee some hard choices around choosing that timeframe and sticking to your decision to reimplement when the time comes.
By the nature of software the "construction" part doesn't really apply. If you only replicate already-designed pieces of software, that's more like creating accounts in SaaS or deploying code to new servers.
Slowly but surely you won't be able to hire new people into the team and your development won't be as efficient as in newer technologies.
But what is left is still discovery/inventive work.
That’s because in software, anything repetitive gets factored out into libraries and platforms.