Pushing out something completely broken that doesn't do what it's supposed to is definitely not going to work (duh!). Pushing out an app that solves the problem of managing shopping lists that has a bug where it doesn't work given a particular set of circumstances will still lead to many people using it if the users don't have any alternatives and it's better than using a piece of paper.
Software quality is important to companies because it means that they can spend more time building features instead of fighting fires, and because low quality represents a threat that a competitor could launch a better, less buggy app. Users mostly don't care so long as the app works well enough to do what they need it to do (but they're not dumb, they'll still pick the least buggy option if there are alternatives..).
A high level of quality in software is not important unless you're entering an already well-served market. I wish it was.
This is true and, once you get over the myopic code focus that most of us shared in university, incredibly self-evident. "Users prefer to use the thing that solves their problem better than not using the thing." I mean... yes?
The real takeaway is that "software quality" means something very different to users than it does to developers. Developers want efficient, ergonomic libraries, aesthetically pleasing logical structures, and elegant software designs. That's what we call "quality". Users just want their damn problem solved, and if they can GET software like that which solves that problem, then you bet they'll buy it, but if they can't then anything which actually solves their problem is far better than doing it by hand.
This was the first big lesson I learned out of uni and it's stuck with me ever since. If you're interested in making commercial software, you're not there to solve the problems YOU think are important, you're there to solve the problems YOUR CUSTOMERS think are important.