Don't marry your design after the first date
Prudent dating advice would be to get to know someone first, before making an everlasting commitment to them. The same advice holds when designing software systems. Don’t marry yourself to your design decisions before at least getting to learn more about them first. Once you have learned their quirks and seen how they act under pressure, you can make a much more informed decision about whether you want to commit. When I am designing new software from scratch I often think about this quote from Uncle Bob.
Good architecture allows major architectural decisions to be deferred. The job of an architect is not to make decisions, but to defer those decisions for as long as possible, To allow the program to be built in the absence of decisions so that decisions can be made later with the most possible information
At the point you start a new project, you have the least amount of possible knowledge about that project. As The Project Paradox states, this is the worst possible time to be committing to major decisions.
The project paradox: making the biggest decisions when knowledge is at it's absolute lowest. pic.twitter.com/b7zBa4Aq7m
— Tobias Fors (@tofo) September 18, 2014
The more time you spend in the problem space, the more information you can gather and the better decision you can make when the time comes. For example, you can probably start working on your domain logic without knowing how the data is going to be served to the client, or what particular flavour of database you are going to use. Once you have chosen a database, by carefully encapsulating the access logic, if it turns out that this database isn’t the one, it is much easier to part ways amicably.
Structure your code in such a way that you don’t have to commit to major decisions up front, and perhaps you too can live happily ever after.