Uses
There are a number of common use cases for geenee. Most take advantage of distributed maintenance.
Maybe you want to promote a particular framework or tool with templates.
By letting someone create them easily, you open the door for many adopters.
Also, you can update a rapidly changing tool without leaving your legacy users stranded.
You might even provide multiple templates with the same input types, so that potential adopters can decide which best suits their needs.
If you regularly create similar code bases, you could save yourself a lot of time. Not just creating them, but also maintaining them over time.
For instance, an app development company usually evolves fairly consistent preferred architectures. geenee makes them much easier to use and to update.
It is hard to coordinate between developers. They tend to prefer to do things in different ways. But maintaining a clear separation between templated and custom code makes it far simpler to hire someone for a single change that won't affect the rest of the code.
Also, it can be much cheaper. Rather than having to hire someone capable of architecting it, you can hire a basic developer at a fraction of the cost. They will have to understand much less, and they can do a lot less damage, because their code is limited to designated custom locations.
Even if you build a tool from scratch, it can be a chore to keep it updated with the latest packages.
Sometimes, when a tool that you used makes a major breaking release, it can be hard to upgrade your code that was generated with the tool.
Sometimes, you find that you want to update your architecture entirely. In some cases, the custom code that you are porting might be very small. You may even be able to replace your template while reusing the same custom code.