# The price we pay when software eats the world

tldr: Collective bidding with enforced price drops for software is 💯💯💯

Imagine a enterprise software company is considering building out a new product. It will cost them \$100,000 to build. They think the best price is about \$30 per month per customer. Let’s say all customers are likely to use it for about 3 years, so the lifetime price paid per customer is \$1000. The company thinks they will get more than 100 customers at that price, so they move forward and build it.

That’s the base case: \$100,000 cost, \$1,000 per customer, estimated number of customers: slightly more than 100.

Under adaptive pricing, the price per customer would go down by a factor of 2 if 4 times the number of customers committed to the lower price.

If 400 customers commit to pay at least \$500, then the price drops for everyone to \$500 and total revenue goes from \$100k to \$200k.

If 1600 customers commit to pay at least \$250 (less than \$10 per month instead of \$30) then the price drops to that for everyone. Revenue goes up to \$400k.

If it turns out that stingy college students are actually a great demographic, with 10 million who want the product, but they’re only willing to pay \$0.10 a month, revenue would go up to \$3.3M!

### Technical Details

The price for a piece of software should be determined by a 30 day auction, where all potential users can enter a bid of how much they’d be willing to pay for full use of the product. If the cumulative quantity of bids at a lower price is high enough such that total revenue is significantly higher than the original scenario, then the price for everyone drops to that lower price.

All bids are of the form: “I would pay x amount or less for this product”. That means as you consider lower prices, the cumulative amount of customers increases. For a given price (p) and the corresponding number of customers at that price or lower (q) you make the following comparison: (Using base condition of 100 customers at \$1,000). If q/100 ≥ (\$1,000/p)^2 then the price drops to p. You do that over and over for smaller and smaller prices, until the condition no longer causes p to go down.

### Assumptions

There are two main assumptions about the supply and demand of the product that if met, would make this pricing strategy work.

#### Extremely low marginal cost (not average cost)

This is true for most software. Let’s consider a single version game without an online mode that’s distributed on the app store. Once it’s shipped, it doesn’t cost the developer anything for the next person to download it. That is an extreme example, since most software requires more cpu time and data storage as the number of users goes up, but the true marginal costs remain very very small.

Customer support is a different good all together and would have to be priced separately. Also, this pricing model doesn’t apply to many of the software enabled companies that sell physical goods or services: Amazon, Lyft, AirBnB, etc. Adaptive pricing would work best for products like YNAB 4 and Sketch3. But I think most if not all software development would benefit if this type of pricing model became common place.

Here’s a litmus test to differentiate between whether the software itself is the asset being sold, or something else: If Congress passed a law tomorrow requiring all code to be entered into the public domain, what would happen to the stock price of the company? Sketch3 would no longer have a way to make money, so their stock price would go down. That’s how you know they sell software. Companies like facebook and amazon would be fine. In fact, they spend so much hiring software developers, that a purely open source world would probably help their bottom line. They don’t sell software, they use software to sell ads and goods.

#### No steep cliffs in the demand curve

Companies that sell goods are out to maximize profits, not maximize reach or impact, and the pricing model must reflect that. It does. As long as the demand curve is smooth, adhering to this model will guarantee that total revenue either remains the same or increases.

### Strictly Better

An optimal pricing model would be “strictly better” than the alternative, ie a constant price of \$1,000 per customer. This model gets pretty close. There are two instances that deserve further attention.

A Steep Cliff

If 390 customers would be willing to pay \$1000 or less and only 10 would pay \$500 or less, then adopting adaptive pricing would lose you a lot of money. Your revenue would be \$200k when it could have been \$390k. So if you have good reason to believe the demand curve drops off at a specific price, then price your product just before the drop-off. But for most products there’s no reason why the demand curve would be like that.

Breakouts

Another concern that people might have is something like, “If 100x people want to buy it for \$1,000 dropping the price is throwing away money!”. The thinking being that if demand is much higher than expected, price shouldn’t go down, it should remain high, or go up!

But this is only true if the supply curve is high and increases with quantity supplied. Demand doesn’t “go up” it shifts right. And if demand shifts right, quantity supplied should go up. So while I appreciate the sentiment, the model adequately rewards breakout products. If the demand is a lot higher than expected, total revenue will be a lot higher than expected.

### Price Discrimination

Perhaps the most important factor in making money selling software today is the ability to price discriminate. This model purposefully does not allow for that. Software as a service companies spend a huge amount of effort and money on getting their customers to pay close to the value that they’re receiving. That’s great for the companies but bad for consumers. And in my opinion, the effort and money spent on that effort represents dead weight loss. There are certainly some arguments for ways in which customer acquisition can improve products, but the modern startup compares CAC to LTV in the same way classical micro economists compare marginal cost to marginal benefit. If you step back and think about that, it’s utterly ridiculous.

Software, once written, has a distribution cost, ie marginal cost, of \$0. It’s time for it to be priced that way.