☁️ Selling storage, compute, or bandwidth
An contrarian take on usage-based billing models for infrastructure companies.
Software developers regularly outsource complexity by buying tools that help solve their problems. This gives them superpowers. These developer tools enable average Joe programmers to build software with complex features like single-sign-on, product onboarding flows, or collaborative document editing - features that can take weeks to build. Great tools turn any developer into a 10x engineer, and the best developer tools can level up an entire ecosystem. But how do these tools make money?
Developers are expensive, and saving them time is valuable! But it’s impossible to add “time saved” as a line item on an invoice. So instead, tools companies charge money to use their software. But what business model makes sense?
In the old days (any time before 2010), software was purchased mostly via licenses. If you bought the license, you were allowed to use the software. This aligns with how developers build software. A company pays a developer to build some software (which takes the bulk of the time) and then continues to pay them to maintain it (which takes less time, but continues perpetually). Software licensing models usually looked the same, with an upfront cost and a recurring fee.
This model made sense, because developers ran the software (such as Java Enterprise Edition) on hardware in their datacenter. Most importantly, developer tool licenses didn’t charge for incremental usage of the underlying tool. If a developer bought a Java Enterprise Edition license, they wouldn’t incur additional expenses for writing more lines of Java code. Instead, these licenses were normally based on the number of machines running the software. More machines, and a more expensive license.
But then, developers stopped running software on their own hardware. Rapidly, software started running on shared, ephemeral hardware. The Cloud! As developers began to adopt cloud computing, usage-based billing started to rise in prominence. Why? Well, this was much cheaper than the other way. Instead of paying $100,000 for a bunch of servers, a developer could deploy the same amount of compute with no up-front cost and run it for a fraction of the total price. What a steal!
Cloud computing also enabled more modularity in software engineering. Because code no longer needed to be co-located in a data center, a developer could run “managed services” — cloud software that was maintained by a vendor — alongside their code in the cloud. An example of this was Amazon RDS, a managed relational database. These managed services would charge not only for their underlying compute costs, but also the number of requests made to the managed service.
This is the original sin for usage-based billing models. Developers were paying for the compute cost to run these services, but also a tax for transacting with the managed services. This “double dipping” unlocked a paradigm shift in how infrastructure products could capture value from software products building on top of them. Instead of simply capturing the value of the saved engineering time, with usage-based-billing, infrastructure companies began to capture the upside of the products built on top of their platforms. In a way, infrastructure companies had created a tax on success.
This aligns incentives. Infrastructure companies need their customers to grow, because that’s tied directly to their bottom line. Moreover, it has inspired a whole generation of “infrastructure” focused on wedging themselves in the critical path of customers. Legacy companies that may have depended on licensing in the past, have reoriented their pricing models to capture the upside of their customers.
Behind all the complexity, developer tools make the majority of their money by selling storage, compute, or bandwidth. Almost everything else is a wrapper on top of this. If a developer tool hasn’t figured out a way to sell one of those primitives, their upside will be extremely limited. And if almost every infrastructure business model can be boiled down to these primitives, one might ask themselves, “Why isn’t Amazon building this?”