> When you add a project that is built from scratch without using a framework that has strong stances on how files should be organized, all bets are off. You have to spend a lot of time trying to wrap your head around the custom abstractions that have been built - and it is hard to argue that some of that will translate to a different job.

I've worked in projects like this. In most cases, they contained what amounted to a part of a framework. The catch in the ones I worked on is that the authors had not realized they were building a framework and so did not think through their division of functionality, cross-cutting concerns like logging, and so on.

Inevitably, each of those had started as simple project. Over time, they had accreted one easy add-on after another. Eventually they're large, complex, and difficult to work on for anyone who didn't create them.

It's been my experience that most projects tend towards complexity over time. A well-chosen framework will require a bit of complexity up front to get going and provide a lot of options you can integrate as your needs grow. Preferably while letting you focus on the specific things you need that are different, rather than having to think about how you want to do logging and so on.