Enterprise software stays profitable not because the code is good — because the switching cost is total.

On r/ExperiencedDevs a developer (u/ChiefAoki) who has transferred through multiple acquisitions at a big conglomerate posted an observation: “every single organization I have ever worked for has their flagship product running on sloppy spaghetti code written by people who don’t give a shit a decade ago, long before AI and agentic coding was a thing.” The OP was asking why customers still pay enterprise prices for products built on this. The 113-comment thread converged on a single answer the OP hadn’t named yet: the code was never the product.

u/Extra-Organization-6 gave the cleanest one-line version in the comments: “switching cost is the real answer. Once an enterprise has built 15 years of business processes, compliance audits, and team knowledge around a crappy codebase, rewriting it means rebuilding all that context too. The codebase is the smallest part of what they’re locked into.” This is the structural reframe. From inside engineering, the product looks like code. From the buyer’s seat, the product is the bundle: code + integrations + compliance certifications + procurement contracts + the institutional knowledge of which fields in which forms map to which downstream system. The code is maybe 10% of the bundle. The other 90% is what got built around the code over 15 years, and that is what the customer can’t replace.

Three other commenters arrived at the same conclusion from completely different angles. u/SpritaniumRELOADED: “In 99% of software, bugs are considered acceptable. There is no business need for refactoring, and when the codebase becomes impossible to work on, a rewrite is done to start the process over again.” u/pydry pulled out the macro pattern: “Have you ever wondered why the tech industry has startups and other industries seemingly don’t? Why a small company with limited resources in tech can on occasion clobber an enormous behemoth?” The answer is that in tech, the bundle-around-the-code is thin enough that startups can disintermediate it; in industries with thicker bundles (regulation + supply chain + capital equipment), there are no startups. And u/Aleks_Zemz_1111 (who runs precision industrial machinery) hammered the same nail from yet another angle: “spent years writing React before realizing the tech industry is exactly the same as the factory floor. Management doesn’t care about the machine. They care about whether the line keeps moving.”

For an indie maker calibrating where to compete, the strategic implication is concrete: if you are building a product whose value is the code itself, you are exposed to anyone who can rewrite that code — and AI just made the rewrite cheap. If you are building a product whose value is the bundle around the code (workflows + integrations + trust + recovered context that lives in customer heads), the code being mediocre is fine, sometimes even an asset because it deters rewriters. The thread’s lesson isn’t that good code doesn’t matter — it’s that good code is not the moat. If your business model assumes it is, you have a strategy problem the next refactor cannot fix. The defensible position for an indie SaaS is identifying which 90% of the bundle you can build that AI can’t trivially reproduce — the relationships, the proprietary data, the workflow embedding, the customer support depth. Then the code is just the part that has to merely work.