Earlier quoted context omitted.
I've had employees try to the "build a better solution" approach behind my back. The big problem with it is that it assumes the person actually has the full picture. In a small project, that may be the case. But often it isn't. In the case I have in mind, said employee delivered a solution that did in fact do most of what our current solution did very well with little complexity. But it utterly failed to account for…
Why weren't you communicating the strategy and vision for the product? That's a failure of management. Each layer in the structure should be given and understand the vision and goals of the immedeiate layer above them so that they can creatively execute and improvise excellent solutions instead of being locked into a plan.
At some point, especially when dealing with senior developers in a fast moving startup environment, you have to assume you're dealing with reasonably responsible engineers who understands that if something doesn't make sense to them immediately, their first instinct should not be "I can rewrite this component that isn't remotely part of my job in a few weeks, no need to ask anyone", but rather to ask "what am I missing? Please explain this to me".
I've personally come across many cases where something looked trivial to do better, and occasionally I'm right, but I'm also humble enough to go ask the questions before I put aside the work I've been asked to do and go off to rewrite something else.