I have mixed feelings about this. Big projects, while definitely having more capacity (engineering efforts, documentation, etc) than your local team, also have

I have mixed feelings about this. Big projects, while definitely having more capacity (engineering efforts, documentation, etc) than your local team, also have bugs. And sometimes serious ones. Plus, more often than not, those bugs are exploited via automated tools. Having a good custom framework will often be immune to these "low-hanging-fruit" scannings. During my career, I've developed custom frameworks (way more than I wished for - at least 4), and they all came out of specific necessities - stuff existing frameworks either lack, or catered to the lowest common denominator that wouldn't fit the desired approach. Most of them started on top of existing frameworks, extending over time, upto a point where they basically replaced most or all functionality from the base framework. They weren't perfect, they had bugs, of course - but often worked quite better than the code they replaced. The one thing I learned while doing this is that it works well - you start from a familiar, robust system, and focus your effort on what you need to improve on your specific scope (eg. module initialization, event handling, database extensions, templating, etc) over time and as needed and to cater your needs, but using a holistic approach - design for big picture, implement for a specific case that can be extended. However, there are some pitfalls with this approach to take into account - integration with the base framework should be well thought of, and clearly defined in a way to reduce coupling and avoiding the situation where you have to maintain your own dogfood as well as the integration with someone else's dogfood. This often isn't easy, and requires a bit of planning, but it can be done.