[sneek_]

I totally hear what you're saying. One thing I can say extremely confidently is that while my agency was eating our own dogfood with Payload during 2020/2021, we released some large projects on Payload and have kept Payload updated in all of those projects since. It's been seamless. A large focus of ours since the beginning was to identify an API that could reduce breaking changes to an absolute minimum and to restrict the use of other packages wherever possible, to avoid the NPM whirlwind. Our config-based approach has delivered exactly that. All of our projects, and our customers' projects, built even before beta release have been updated without issue. But this is certainly systemic to NPM and especially if you look at packages that are of lesser quality. That's the classic downside to the way that the JS ecosystem does things - it's basically open-ended at every turn. Even with React. But I am very confident, having had experiences very similar to yours, that it's handled quite effectively with Payload.

On another note, one of our goals with Payload was to rigorously minimize the amount of learning that you have to do to get up and running with Payload's specific conventions. This was a huge requirement of ours while we designed our initial API. We've always _hated_ having to learn the intricacies of another platform like Drupal or WordPress before being able to be proficient in those systems. It's like you have to get a degree in the CMS before you can use it rather than sharpening your skill set with the underlying language.

Payload's conventions are quite flat and are all config-based. From there, you write your own code to do whatever you want in the conventions that you're used to.