But in all seriousness, I would strongly advise against building your own framework if possible. As many of the other commenters have noted, frameworks nearly always start out clean and beautiful, but turn into a liability later on. There is so much that is required in a framework that you probably won't be able to see or anticipate until much later down the road, when it is already in place, and at that point is becomes much more difficult to add the features you suddenly realize you need.
Before even thinking about building your own framework, really study the options currently available, because you'd be far better off building a powerful library over an existing framework that will suit your needs. This allows you to push the difficulties of building a framework further down the stack and lets you focus on building your application with the structure that you want, which is really what you want to do. Only when there are no options that work, and when your intended design is fundamentally different from all other options, should you consider building your own from scratch. This means that it would be very difficult or nearly impossible to build what you want in any existing framework, and your desire is to build a tool that works completely differently from the others, and that this new way of working with it would allow you to build your ideas significantly more easily.
A great example of this that comes to mind is OctoberCMS, which is built on the wonderful Laravel PHP framework. This abstraction allows developers to use all the existing Laravel features when it comes to the tricky bits of web servers (like routing, background jobs, and user sessions), and allows the CMS to focus on being the best CMS it can possibly be (great UI, really easy to build highly customized plugins, easily extending other plugins, etc.). There are other modern PHP CMSs I really liked and really wanted to stick with, such as PageKit, but because they were a fully custom framework, there were just limitations to the framework that prevented me from doing what I wanted with it, and they were all in the lower-levels of the stack (like the ORM) not the CMS portion itself.
I can say this because I have been on both sides of this discussion. I have personally been in a situation, building a custom framework for a client, where I later found solutions on the market that solved many of the problems the client had better than I could. If I had really evaluated the existing options before starting to build this custom framework, I would have found it would have made more sense to bend that framework to my client's needs than to build the custom solution I had. There's a lot of custom stuff I would have needed to build on top of that framework, but the end result would have ended up cleaner, faster, and more reliable than the end result we delivered. Not to say that our solution is bad, just that it could have been better if I could focus on the clients needs and spent less time building the framework portion.
On the other side, I have been having great success building my own framework for static websites, Orchid, which approaches building static websites in a way that no other tools on the market do, across all languages. I had studied all the popular options, and many of the less-popular ones, to see if any of them could be made to work how I wanted it to, and when they all came up short I started building Orchid. But I will say that this process of building Orchid has turned into something much, much larger than I anticipated going into it, and it has taken a lot of time and dedication to keep the code beautiful.
Building a framework is not for the faint-of-heart, and it takes a lot of dedication and love to make a custom framework perform as you want it to. Only consider building a custom framework when you have completely exhausted all other options and found your needs to be fundamentally different from the solutions currently offered on the market.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.