Create templates to quickly answer FAQs or store snippets for re-use.
The kid inside of me, who loves to code, says heck yeah, let's do it, however, the software engineer considers building something that might already exists a non-optimal, so at the end I guess it comes to the cost (complexity and time) against the benefit (learning and customization) of building it.
I would probably try to create a well documented company library of "parts", that you can use with an existing framework.
This way you don't have to maintain an entire web framework. If you build an internal framework you have to maintain it, keep it updated, solve security issues, train the developers and so on.
Also people might not be happy that they are using something that has literally no community to interact with :D
I have an exclusively academic approach, so in the interest of learning how a framework comes into existence, learning how the inner workings... Well, work - then I'd definitely say yes; when can I begin?
The Open Source community has developed such great software that I don't really find the need to make a framework or library. I'm much more inclined to learn how to contribute to already great projects.
I would only make a framework if it arose organically out of a certain need. If I was faced with a type of job that no framework addressed well enough, I'd make something specific to that. If I saw other people struggled with the same thing, or used this framework many places, I'd consider making it an open-source framework I help maintain and all.
I figure if I built it out of a serious need, and other people came to it for that same reason, that'd be a natural, powerful driving force for people to help build and maintain it.
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.
Would it be cool to as a learning experience? Sure. But I feel even large companies that build frameworks, a lot of them just kind of materialize into existence after creating something for a certain project. Then they see they can then turn it into a framework.
So I'd just create a set of tools, libraries, and SDK's and while I'm doing that it turns into a framework then we will go from there. Though for the most part I would ask why I thought I could create something just as fast, secure, and stable as an existing framework.
The out come of looking at existing solutions proves that they are not as useful for what my scenario requires. I have a complex app that uses a custom FSM and a staged reactive RxJS logic graph for data-flow/control (lots of innovation here). Typically the logic is put into components but I find it is better extract it and just use something like lit-html for DOM patching.
I like the library approach and being able to swap technologies in/out of my app instead of putting all my eggs into one existing framework. The popular frameworks are only monuments to yesterdays issues. So yes, I have a better way of constructing my app than what the existing frameworks offer.
Let's assume there's nothing comparable on the market and you think about building this framework in your free time - so you only have to reason about this with yourself - and you're really keen on building this thing, then yeah, dig in!
However if your employer has given you a task and you consider that a good solution involves building a new framework, well, then there are so many more things to consider. Many have already been mentioned, but I like to add: who's going to use it besides you? If you have 30 developers in your company who will build stuff on your framework, then it's gonna be a big deal. Since your employer will rely heavily on it, there will also be some developers supporting you in writing docs and maintaining this thing. So... let's say "maybe".
But if it's only you and one or two coworkers, then don't. Try to build a library instead, because a library might help you for now nearly as much as a framework could, but it's not that kind of a burden as a framework is. A framework is a barrier. It changes the rules of the game. Developers need to learn it before they can start doing their job. But you should work on the opposite - you should decrease on-boarding time of new developers and make them productive as fast as possible. Not only your employer will thank you, but also your future you. ;-)
No I would not. Here is further explanation of my perspective.
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.