The biggest counterpoint that I can think of to actually putting your own framework into production, especially if it's a one man/woman show, is security. A lar

The biggest counterpoint that I can think of to actually putting your own framework into production, especially if it's a one man/woman show, is security. A large open source framework will have implemented and fixed a ton of security blunders which you will not have. It doesn't really matter how encyclopedic your knowledge of software architectural patterns is, even though design is important for system security, there is a large component that is case-by-case attack mitigation. Your almost always going to be better off with a security conscious framework than with an ad-hoc framework. Another way to look at it is that every production framework needs a subset of its development team that is really knowledgeable and paranoid about security, proactively watches for new attacks, and which can very quickly roll out effective mitigations. If you don't have at least one person on your team that will handle this role, then you're better off using a security conscious framework, and if you only have one, then they'd better be very good. Otherwise, sure, make your own framework to learn architectural principals, to improve your ability to digest the architecture of production frameworks, and to improve your ability to extend the framework into areas that are unique to your use case. Just keep it out of production. [disclaimer to avoid discussion forks: for this comment, I'm assuming that the framework is being used for non-trivial systems, if what you're doing is trivial, then you may not need a framework at all, bespoke or otherwise. I'm not particularly interested in the question of what constitutes a non-trivial system. Set the bar wherever it makes sense to you to consider significant code reuse imperative.]