By "Make decisions easy to change later", do you mean,
1. Getting the Module structure of the system correct with well defined contracts between them so that they can be changed, updated independently of each other.
To move the project forward, at some point you have to make decisions based on incomplete information. Some of these decisions will be good, some will be ok, and some will be completely wrong. The problem is: You only know this after the fact, when parts of it or all of it is already implemented.
Because of this you should design for change and build a flexible architecture. My goto technique for this is to encapsulate everything regarding this decision into a module and put an interface around it. The interface stays the same, the implementation can adapt. How this interface looks like is not that important. You can build a library, it could be a REST API or some gRPC thing, whatever. So yes, the main idea is to create well defined contracts or interfaces (call them whatever you like), which will be be flexible enough to adapt to different implementations.
By "Make decisions easy to change later", do you mean, 1. Getting the Module structure of the system correct with well defined contracts between them so that they can be changed, updated independently of each other.
Thanks for your inputs.