Was that meant to be ‘is’?
The fact that you redefined “clean solution” as “correct compromises” doesn’t say much unfortunately.
Sure, sometimes everything works out where you can refine something to the point where it’s a golden (or near perfect) solution, but any solution that meets business requirement x is better than one that does not at all.
I’m not sure if it really comes down to this, but my standards for internal tools are much higher than things developed on the customer facing side. I think I mostly attribute that to the fact that we know how to successfully develop our user/business requirements versus our customers who do not. Hell, I have customers who have asked us to write their requirements. That’s a huge red flag for an unsuccessful solution.
A correct solution, even when not clean, isn't going to earn money. No one (except perhaps textbook publishers) will pay for a solution that is clean alone.
You can clean up a correct solution at a later date, all the while maintaining correctness; a clean (but incorrect) solution might need to be completely redesigned to make it correct.
I've come to accept that the best engineers are those who ship (you don't get to 10x productivity if you don't ever ship) and that often means being able to call the correct compromises to make. Heck, I'd even say engineering in general is finding a working compromise given a set of constraints.