I work in a company which creates and maintains a dumpster fire product, closing on 20 years now. The product is neither fast nor correct. It has more tech support than developers (and our tech support writes code and solves problems usually associated with development, except, essentially, they are hot-patching the garbage our developers produced, live, at customers' site).
The company was acquired a year ago by an international giant, but it didn't really change on the inside.
So, what's the secret sauce? -- Exclusivity. Competition died off 10-15 years ago. The company used to compete with some big names in the field, but all those withdrew long time ago. So, we won.
Unfortunately, this is also a "success story" of many other companies, some of them I even had a (dis-)pleasure to work for. This is also a solid market strategy: don't compete, find a market niche where you offer a unique service. Once you are there, do the absolute minimum to make users happy: over time you will have accumulated enough features and unique workflows that are virtually impossible for the competitors to replicate, at least not with the kind of funding a typical start-up may go into town. Also, new features are easier to add, and they bring about as much of customer satisfaction as improving the old and broken stuff. The novelty factor makes it look like customers are getting more treats, but the treats are really low-effort.
In the case of a monopoly like the one I'm in, users feel trapped, often they don't even know how much better their software could potentially work, they accept ridiculous gaps in quality because there is no alternative. The requirements to performance and reliability are thus at the absolute minimum, and often lower.
---
Just to give you a practical example of what I'm talking about: recently, I discovered that some genius from the department which is responsible for the core component, a service that, beside other things is responsible for processing and saving configuration submitted by users has implemented "buffering"... nevermind that it's working on Linux, with filesystem API which already does buffering and caching... But, unlike Linux filesytem API, this NIH caching will lose user's data if the service stopped after acknowledging the save to the user and actually writing data to persistent storage. Nevermind that amount of data it has to write is negligible (at most few Megabytes). Nevermind that it's typically an interactive operation where users are in no rush to write such data...
I couldn't even convince the team responsible for the component that there's a problem... let alone do anything about it.
And, yes, our product used by some of the largest / wealthiest companies in the world.