Open Salesforce, SAP, or virtually any enterprise resource planning tool on a Monday morning and you’ll notice something. The interface looks like it was designed by someone who had heard of good UX but never actually experienced it. Cluttered dashboards, menus nested four levels deep, buttons that look like they belong on a 2003 intranet portal. This isn’t an accident, and it isn’t laziness. There’s a cold, structural reason enterprise software looks the way it does, and once you understand it, you’ll never look at a B2B tool the same way again.
The economics of who pays for software shapes everything about how it gets built. This same dynamic explains why free apps often cost more to build than paid ones, and it applies with even more force in the enterprise world.
The Buyer Is Not the User
In consumer software, the person who pays is (usually) the person who uses it. If Spotify’s interface frustrates you, you cancel your subscription. The feedback loop is tight and brutal. Companies that ignore it die.
Enterprise software breaks this loop entirely. A CTO or procurement committee buys the software. A finance team, a sales force, or a warehouse crew actually uses it. The people signing the contract rarely spend eight hours a day inside the product. The people who do spend eight hours a day inside it had no vote in the purchasing decision.
This creates a simple but devastating incentive structure. Enterprise vendors optimize for the people who write the checks, not the people who click the buttons. Procurement teams care about compliance features, security certifications, integration capabilities, and price. They do not care whether the font size is comfortable or whether the navigation makes intuitive sense. So vendors pour resources into compliance checklists and feature matrices, and UX gets whatever budget is left over.
SAP is the canonical example. The company’s ERP suite has been the dominant enterprise backbone for decades, running payroll, supply chains, and financial reporting for thousands of major corporations. SAP’s interface has been famously hostile to users for most of that time. The company has known this. There’s an entire ecosystem of SAP implementation consultants, training programs, and third-party UI layers whose sole job is to make SAP usable. None of this friction has meaningfully threatened SAP’s dominance, because the people experiencing the friction aren’t the ones renewing the contracts.
Switching Costs Are a Business Model
Here’s where it gets more deliberate. Enterprise software vendors don’t just passively accept ugly interfaces. In many cases, complexity is a strategic asset.
The harder a system is to learn, the more expensive it becomes to leave it. When a company’s entire accounts payable team has spent three years learning the quirks of a particular system, the cost of switching to a cleaner competitor isn’t just the license fee. It’s retraining hundreds of employees, migrating years of data, rebuilding integrations, and absorbing months of reduced productivity during the transition. A 2019 study by Nucleus Research found that data migration alone accounts for roughly 25% of ERP implementation costs.
This is the same logic that keeps legacy programming languages entrenched across the industry. As we’ve explored before, Google, Meta, and Apple still run significant infrastructure on programming languages from the 1970s because switching costs compound over decades. Enterprise vendors understand this intuitively. Every hour a user spends learning your system’s idiosyncrasies is an hour of switching cost being deposited into a moat.
Feature Bloat as a Sales Tactic
Enterprise sales cycles are long, often six to eighteen months for major contracts. During that time, the vendor’s sales team is responding to RFPs (requests for proposals) that list required features. The more boxes a vendor can check, the better their odds.
This creates a relentless pressure to add features, not to refine them. A product manager at a mid-size enterprise software company might be asked to ship a feature not because users have requested it, but because a single large prospect put it in an RFP. The feature gets built, it gets added to the marketing materials, and it gets crammed into an interface that already has too much in it. Multiply this by ten years and dozens of enterprise clients, and you end up with dashboards that look like airplane cockpits designed by committee.
Consumer product teams talk constantly about what to cut. Enterprise product teams are almost always talking about what to add. The cultural difference produces visibly different software.
The Support Calculus
There’s another factor that rarely gets discussed: enterprise vendors have a financial incentive to keep interfaces complicated because complexity generates professional services revenue. Implementation consulting, training, and ongoing support contracts can represent 20 to 30 percent of total revenue for major enterprise software companies. A genuinely intuitive system would cannibalize that revenue stream.
This mirrors a broader pattern in tech where the support model shapes the product. Tech companies pay engineers $400K but let robots answer your support tickets precisely because the economics push them in that direction. Enterprise vendors make the opposite calculation: complexity justifies expensive human support, so complexity persists.
Why This Slowly Changes
The model isn’t completely static. A new generation of enterprise tools, Notion, Figma, Slack, Linear, has demonstrated that B2B software can be genuinely pleasant to use. These products grew through what’s called a bottoms-up or product-led growth strategy: individual employees adopted them voluntarily, and adoption spread until IT had to formalize the relationship. The user and the economic decision-maker were briefly the same person, which forced design quality.
The incumbents have noticed. Salesforce acquired Slack. Microsoft has spent years trying to modernize its Office interface. SAP has invested heavily in its Fiori design system. But these are retrofits on top of architecture built for a different incentive structure, and it shows. Cleaning up decades of accumulated complexity is genuinely hard, and the pressure from procurement buyers to add features never stops.
Understanding this pattern matters beyond just enterprise software. The gap between who pays and who uses a product shapes design decisions across the industry in ways that aren’t always obvious. Consumer apps have their own version of this problem, as anyone who has watched productivity apps quietly make their users less productive can attest. But in enterprise software, the misalignment is structural, durable, and, for the vendors, extremely profitable.
The ugly interface isn’t a bug. For many enterprise vendors, it’s a feature they have no particular interest in fixing.
