It is wise to carefully think about the consequences of choosing a framework will have.
But the most important thing is to understand the business problems before you choose a specific technology to implement the solution to those problems (or requirements).
You should always consider that the business logic code or let's say the code that will implement the solution to your requirements is your most precious good.
So there are ways to implement the important (business) logic code in a way that is free from framework code and thus free of dependencies other than your programming language.
If you keep that in mind and always separate your business logic you will be able to switch to another framework in case that you encounter limitations at some point. Going this way also comes with other benefits such as better testability, readabilty and maintainability. For instance, if you keep your business logic code free of ORM or Active Record dependencies you will be able to change the components for database communication without affecting your business logic code.
Looking into Clean Architecture or Domain-driven Design can help you achieving this goal.
Note: implementing strict abstractions between business logic and interface concerns of course also adds additional effort and might not make sense for "small" and short-lived projects without complex business logic. But in such cases choosing the wrong framework and not having the mentioned abstractions will not have the same bad implications as for big and long-lived projects with complex business logic.