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.
The idea is that it does what it says on the tin, without fanfare, robustly, usably, accessibly, localizably, and dependably; providing a user experience that gets out of the way of the user, in a manner that does not surprise the user (even "good" surprises can be an issue. Boring software can be just what the doctor ordered).
In my book, that's the definition of "quality."
I'm working on an application that has been over a year in the making. Its functionality is something that I could have popped out in a month, but making sure of the Quality of the app has necessitated that I spend a great deal more time, "polishing the fenders."
If this were a commercial app (it isn't), then it would have been unbearably expensive for a startup.
I tend to write test harnesses in a day or two, that have similar levels of functionality to this application.
High Quality is significantly more expensive than even "decent, but lesser" quality.
What happens if you release it and it turns out that nobody likes it? I'd have preferred to spend a month releasing a lower-quality app, and then spent 11 months improving it (while people use it and I learn more about what they want) rather than take a year releasing a high-quality app nobody wants to use.
This assumes you aren't just building it for fun, though, in which case building it is the point, and you don't even need to release it afterwards.
But I also follow a development methodology that I call "paving the bare spots."[0] It adjusts the design, as the project progresses. Not for the faint of heart. It means that I may toss out a month's work, because it does not fit the user experience (which is under constant revision). We have also made a couple of major pivots, during the project, to fit new realities.
I have probably tossed out three months' worth of work, as the project has progressed. Happy to do so. The best code, is the code I don't write.
The nice thing is, is that the product is constantly at "ship" Quality. Makes demos, user testing, and begging for money, easier.
[0] https://littlegreenviper.com/miscellany/the-road-most-travel...