And I'm just thinking about the amount of time people spend paying me to work through these bugs with the team at the startup building it.
Putting aside the whole "it's easier to keep a customer than it is to acquire one" and "easier to keep your good reputation that overcome a bad one" side of things (and there is one tool a client asked me to use that I told them either the tool goes or I do),
Ship out the product, even if it isn't ready. Meet your performance goals for shipping on time. Collect your bonus and exercise your stock options. Bail to another gig before the consequences for the buggy product hits the fan.
A recent one was that Azure Backup and Azure Update don’t work in combination! If you restore a VM, it can never again be patched by the update system. (It won’t recognise the OS as supported and just refuses to do anything.)
It has been reported, but nobody cares. I was told by support that this is a “will not fix” because it’s not a requirement.
There is no way anything this catastrophically bad would have made it past QA back when Microsoft used to have an actual QA team.
I swear there is a significant portion of development teams out there that are secretly pleased as punch that they can just push whatever garbage they want straight to production without the pesky people in QA “just complaining” and being “obstructionist”.
Backup: check!
Update: check!
Backup + Update both working at the same time - not on the list.
Fast forward to today, and it's way cheaper to ship code with bugs to prove out an idea works than it is to spend even a few minutes writing test cases and doing even a modicum of QA.
Ultimately, it's a not just a combination of all 3 things you've mentioned, which are all contributing factors; the real problem is any level of QA before proving an idea is seen as a waste of time and money. As someone who started in tech support & QA 30 years ago, it's really tough to see.