When you are fundamentally incapable of reacting to a change in underlying technology or product direction, you’re placing a high-risk bet on the hope that such a change never becomes critical. For short-term projects, that might be a safe bet. Over multiple decades, it probably isn’t.
One helpful thing you can do (I'm sure this will be mentioned later), is to understand which aspects will have a short lifetime (or shorter, at least) and which will have a long, or a which aspects are easier to change and which are hard.
"IADA," something I learned many years back, is one such framework. It states that, in general, Identifiers are the hardest to change, followed by API, then Data model/storage, then Architecture (i.e., changing implementation is the easiest).
So, that can guide how much effort to spend on future-proofing things (in decision, design, or implementation). i.e., it's more important to spend time ensuring your get identifiers and APIs right than it is to get data storage right.
