You'll usually start developing some feature or application because you think you can create something or improve something else. You'll probably get excited and talk about it and at some point, come across the people that you thought know it all and will catch your drift and help you accomplish whatever it is you want. I've been proven wrong there. Mind that I'm developing a customization tool build upon existing release engineering tools, this doesn't hold up for entirely new tools.
The real test isn't the code. The real test isn't all the bugs you'll get either. Neither does it concern you, what huge pile of feature requests you'll get, or what number of bugs will show up once you try and implement some of these requested features, breaking other stuff in your code. Hell, there's no challenge in doing it 'enterprisey' either. The challenge you had in mind was to get things done, to move forward. That is what it is all about, and that just so happens to be what you're really good at.
Neither of all that is a real challenge, believe me.
The real challenge is to continue working as you see fit, because you'll get flamed from all sides that has people with a different perspective on things. The real challenge is to withstand the temptation of just quitting.
Continuing on building a customization application upon release engineering tools; I'm sure you can appreciate the different perspective on things. Whereas release engineering tools need to be stable and consistent, customization tools can just have their way with it. Don't overestimate the number of features you can add to a release engineering tool; it doesn't need all that, the tool works as is, so your life then is about discussing the need for this or that feature in some upstream tool, not about doing the code and solving the bugs. You'll give up eventually. You'll let them pull whatever they like from your tool.
This is the Fedora world, where everything moves forward fast, faster, fastest. It's a community distribution that does cutting-edge in stable, and for which enterprise linux engineers decide what progresses slow enough to keep track off changes, or what is too fast to really be allowed to be build upon whatever they are on the receiving end of bugs for.