I come across lots of situations, with legitimately bright developers, who have replaced a standard subsystem either a home-grown one, usually for performance reasons.

In that moment in time, in that context, the general solution was less performant or had an ugly bug, or whatever, so they replaced it with something designed for the one specific context.

But then the context changed, and now heres this bastard-child that's been narrowly designed, and optimised for performance (so hard to maintain or change. ). And the developer is somwhere else.

But equally I've spent a career writing the "new standard solution", which of course started out as an alternative to "the standard solution". And in our context that -has- made a huge difference. So it eould by hypocritical if me to say "stay inside the box".

If you do need to get outside the box, I would give some advice though.

A) documentation. Nobody likes doing this, but this is the most important part. If it's not documented properly, it doesn't exist. And just the act of documentation will show you where the design is deficient.

B) write your code as clean as you can. Make it easy to follow. Make it easy to read. Try not yo be clever and where you are clever don't skimp on the comments. You'll thank yourself for this later.

C) as much as possible try and build for the general case, not the one in front of you. The more useful this vote is the more it'll be used. The more it's used, the easier it is to identify flaws.

In summary - stay on the main road. But if you do need to forge your own path, make sure it's done properly, not some single lane gravel dirt thing.

Sometimes the person really is brilliant and you should do anything to keep them. But if it's because they're the only one who understands their code, then they are a liability.