I cannot upvote this enough.
I recently made the decision to have a third party build a component as opposed to doing it in house. The cost and time to build a component in house vs using a third party ended up being a wash, but the third party offered to maintain and support a solution so this presented less risk to us. This major risk we incurred was in vendor lock-in.
These types of trade offs happen all the time. Think about virtually any SAAS offering that could otherwise be built in house.
Both of those are along the lines of "I need code to do this thing, but I don't want to be the (sole) maintainer."
You could write your own language, IDE, OS, build system, source control, networking library, logging library, shopping cart, payment processor, etc.
[NB To be fair I had the same sense of disappointment myself years before when I was quite proud of a package to do CLOS object persistence and a more experienced chap told me there already was something to do that...]
But buying on margin increases your volatility and risk exposure, so you shouldn't take on more than you need to. Assuming zero transaction costs, it's always a good idea to substitute less code for the same benefit.
Edit: Nice to have a comment downvoted, even though what I said is true.
In programming terms, it's very tempting to say, "this room is untidy, I'm going to build a new one." It's certainly more fun than tidying your room. But this is how you get sprawl and bloat.
Your job as a software developer is, roughly, to deliver maximum business value with minimum cost, and that includes writing minimum code to accomplish the task. That is what the senior developers are talking about when they're saying you've written too much code.
It does sound to me like they've got a well designed system if you can add new features simply by making a small modification and some configuration to the existing code. As long as it's also well tested and well documented (that may be lacking...), you've got the ideal codebase: one in which you can add large amounts of business value with only incremental changes.
You mention that this is "great for the business but not much fun for me". I think this is a sign of inexperience. Part of what makes something fun is how difficult it is. If something is too easy it's boring; if something is too hard it's frustrating. In the middle we find things fun. The reason writing lots of greenfield code is fun for you is because it's easy. Understanding and modifying existing code is harder, and that's currently too hard so you find it frustrating. You need to push past this stage to improve as a developer. As you get better, it will become easier to work in existing code and will stop being so frustrating.