Evolving from MRR to PPU

However, as I started to build more extensions on RoamJS, and as I start to build products that will come after RoamJS, MRR is beginning to feel more like a roadblock than a savior. It's becoming harder to fit what I do in an MRR business model. Because of this, I've started to migrate my business model to "PPU" or pay-per-use. This allows users to only pay for what they use from my product instead of indefinitely.

To better explain why I'm transitioning to this model, I want to first go through the myriad of issues I experienced with MRR.

Phantom Revenue

I assume most people reading this article will have a Netflix account. Has there ever been a month where you didn't watch a single thing on Netflix? Yet, you still had to pay for that month. More generally, how many of the subscriptions that you currently pay for went unused last month?

I call this "phantom revenue". It's the revenue a software service is earning from essentially ghosts who aren't using the platform. Every software app that operates on an MRR business model will have some non-negligible percentage of their revenue accounted as phantom revenue. For the RoamJS Static Site Extension for example, I estimate about half of the users currently subscribed are phantom revenue.

As a developer, this is incredibly nerve-wracking. This means that a large part of my MRR is not dependent on the usefulness of my product, but on the financial diligence of my users, a factor I cannot control. I also have less visibility on which features are valuable enough for a user to want to pay for and which aren't. Not to mention the moral dilemma of taking money from people who are not receiving any value in return.

Reimplemented Salary

When I left my full-time job, one of the conditions I wanted to move away from was having a salary. Salary implied nearly unconditional security. Knowing that I will be able to pay for rent next month regardless of whether I shipped a given feature meant that the quality of my work began to degrade. I couldn't feel the value I provided to users directly, because I received value whether or not I did a good or bad job. Or worse, I couldn't be compensated more if I did a great job.

By chasing MRR, I essentially reimplemented a salary. As soon as I saw some subscribers on one of the extensions, my focus started to steer away from the one I just released to other extensions. I began to ask myself questions like "what is the minimal effort needed to keep this user from churning?". In short, the product quality began to suffer.

Equality of Users

Products that operate on an MRR business model are forced to treat their users equally. This means the user that consumes your APIs only a couple of times per month has to pay the same amount as the power user who is consuming the majority of your allocated compute. This then forces you to price according to the largest user, pricing out all lower tiers of users.

Some products solve this problem by introducing pricing tiers. But this only partially solves the problem, as you still for each tier experience the same problem as mentioned above. Each tier either is abused by the power users who should be paying more or is pricing out users who could be paying less and still get value out of the product.

What MRR pricing tiers attempt to achieve is filling out the area under the "user curve". Every user is different, with different needs and usage patterns of the product. If you take pricing tiers to the limit, what you actually end up with is a PPU business model that could more effectively fill the area under the curve.

The Shift to PPU

I want to shift the business models of my products to PPU to help solve the problems I encountered above with MRR. The revenue the products make will more directly correlate with usage, which would eliminate phantom revenue. This focus on real revenue will hopefully incentivize me properly to keep making the related products more useful, enough to make people want to use it. It will also be a better end-user experience overall as users will only need to pay for what they use.

AWS is probably the industry leader with this business model. As a user, I only have to pay for the amount of computing, network, and storage I actually used. This then incentivizes me to be more deliberate and careful about my usage. Since all of my products are built on AWS, it should also be easier to translate what pricing should look like as I could do it based on a percentage of what AWS resources I use.

The Static Site extension I mentioned above is currently a flat $12/month. The primary expenses I pay happen when someone deploys a new version (compute) and when someone visits the output site (network). A PPU model would charge users based on the number of times they deploy and the number of page visits they receive, which I could track and then charge a percent markup.

Future RoamJS extensions I'm working on, like RoamJS Multiplayer, will naturally fit this mold. Instead of charging a flat monthly fee, users could pay for the amount of computing their multiplayer server will cost.

My non-RoamJS projects are also starting to fit this mold as well. I'm working on an ISA platform to help make it easier for future investors and creatives to form ISA contracts like I did. A monthly fee here makes no sense as a given creative will only sign less than a handful of these contracts. A model that charges based on the contract is more in line with the value the service will provide. Web3 projects also naturally fit this mold, as most dApps make money based on the transactions that occur on their network.

I will continue to maintain monthly subscriptions in the short term as I undergo this shift. But the goal is by the end of 2022 is to have all my products on a fully PPU model.