The only time I've regretted overdesigning is when there's been significant original design work involved.
I don't think I've ever regretted overdesigning to meet a common standard or match how everyone else does something.
A lot of the YAGNI I see is in the form of "We don't need a framework, just do vanilla JS" or "I only need one of the features of this library, I'll just write it myself".
Almost all of my own big tech regrets have to do with building something "innovative". Even when they've solved the problem better than existing solutions they often become regrets, just for the simple fact that they aren't better by enough to justify the nonstandardness.
Ah, I think I wouldn't qualify those as YAGNI decisions, more in the premature optimisation direction. YAGNI is preparing for future integrations that might never happen, or preparing for supporting multiple databases, special users, special circumstances. It is always a decision of doing more work now, versus more work later.
The decision to not use a framework or a library is sort of the reverse in that you're making a decision that you can later reverse by reducing the complexity of your own code.
Definitely agree with you that a part of being a very effective development team is owning as little code as possible, by using as many existing solutions as possible.
I don't think I've ever regretted overdesigning to meet a common standard or match how everyone else does something.
A lot of the YAGNI I see is in the form of "We don't need a framework, just do vanilla JS" or "I only need one of the features of this library, I'll just write it myself".
Almost all of my own big tech regrets have to do with building something "innovative". Even when they've solved the problem better than existing solutions they often become regrets, just for the simple fact that they aren't better by enough to justify the nonstandardness.