The simple version
Software costs almost nothing to copy, so vendors don’t price it based on what it costs to make. They price it based on what it’s worth to you.
Why this feels wrong but isn’t
Imagine you buy a server rack for $40,000. It takes materials, labor, factory time, shipping. Someone built the thing. Now imagine you buy an enterprise database license to run on that rack, and the license costs $120,000 a year. Nothing was manufactured. No materials changed hands. A file moved from one computer to another.
This strikes most people as backwards. The physical object costs less than the permission slip. But the confusion comes from applying manufacturing logic to something that isn’t manufactured.
When a company makes a server, each unit costs roughly the same amount to produce. The tenth server costs about what the first one did. Economists call this a high marginal cost. When a software company copies its product, the ten-thousandth copy costs a fraction of a cent more than the first. The marginal cost is nearly zero.
The moment you’re no longer constrained by the cost of production, price detaches from cost entirely. What’s left is a negotiation about value.
The value-based pricing engine
Database software is a useful example because the numbers are stark and public. Oracle’s database licensing has historically been structured around the number of processor cores running the software. A financial institution processing millions of trades per day and a small retailer running inventory reports are using the same code, but they’re not paying the same price. Oracle isn’t charging for the software. It’s charging for what the software enables.
This is called value-based pricing, and it’s the dominant model across enterprise software. The logic is internally consistent: if your software saves a hospital $10 million a year in operational costs, charging $2 million for it is reasonable by any measure, regardless of what it cost to build.
The problem is that this logic can compound into absurdity, and the enterprise software industry has leaned into that absurdity for decades. SAP, Oracle, IBM, and others built pricing structures so complex that buyers need specialized consultants just to understand what they’re purchasing. That complexity is not accidental. Deliberately opaque terms create leverage for the seller and make it nearly impossible for buyers to comparison shop.
The switching cost trap
Here’s the part that rarely gets discussed plainly: software licenses often cost more than hardware because the software is specifically designed to make switching expensive.
Once a mid-sized company has run its operations on a particular ERP system for five years, migrating to a competitor isn’t a software decision. It’s a business transformation project that takes years and costs millions. The incumbent software vendor knows this. The annual license renewal is not really a renewal, it’s a ransom payment, and both parties understand it.
Microsoft built an entire enterprise business on this dynamic. Office became standard not purely because it was the best product but because once your organization’s files, workflows, and muscle memory are locked into a format, the cost of leaving exceeds the cost of staying. That’s not a conspiracy, it’s a structural feature that any rational company will exploit once it achieves sufficient adoption.
The hardware analogy breaks down here too. You can sell an old server. You cannot meaningfully liquidate a software implementation. The switching cost is the hidden price embedded in every enterprise license, and it’s the real reason renewals don’t look like competitive markets even when alternatives exist.
The R&D amortization problem
There’s a more sympathetic explanation for high software prices that deserves a fair hearing: the cost to build the first copy is enormous.
Large enterprise software products represent hundreds of millions or billions of dollars in development, maintenance, security work, and compliance engineering. That cost has to be recovered from whoever buys licenses, because there is no physical product to sell. A car company sells cars to cover its factory costs. A software company sells licenses.
This creates a genuine tension in pricing. The company needs to recover fixed costs across a customer base while marginal costs are near zero. There’s no natural price signal from production. So vendors anchor on customer size, transaction volume, number of users, or number of cores because those are rough proxies for value and capacity to pay.
The result is that small customers often pay relatively more per unit of value than large ones (who can negotiate), while large customers sometimes pay more in absolute terms than seems justified by any cost-based analysis. Nobody is quite happy, and the complexity of the resulting price structures is a direct consequence of trying to solve an economically strange problem.
What’s actually changing
Cloud computing has started to crack this open in specific ways. AWS, Azure, and Google Cloud charge for consumption. You pay for what you use, when you use it. This forces some pricing honesty because the meter is always running and visible.
But the major software vendors have adapted rather than reformed. Many have moved to subscription models that preserved or increased total cost while offering the psychological comfort of a monthly bill instead of a large upfront license. The throttling dynamics that cloud providers use during peak hours add another layer: you’re paying for capacity you may not always get.
Open-source software is the more genuine disruptor. Linux, PostgreSQL, and a growing stack of enterprise-grade tools have eroded the pricing power of commercial vendors in specific categories by making the first copy free by design. The business model shifts to services, support, and hosting, which is harder to inflate arbitrarily because those have real labor costs.
The underlying economics haven’t changed. Software still costs almost nothing to copy. But competition and transparency do constrain how far vendors can push value-based pricing before buyers find alternatives. That constraint is growing. It’s just growing slowly.
For now, the honest answer to why your software costs more than your hardware is this: because your hardware vendor couldn’t make that work, and your software vendor figured out how to.
