Why all the fuss around Usage Based?

John Swaine headshot illustration
People building bricks

So, dev to dev, why bother with Usage Based Pricing?

Well first of all, you don't know what you don't know. Your product is running, it's starting to get somewhere and now you want to start taking some money from your customers. Or maybe you already have customers but there are other prospects who want a more flexible payment structure than you can currently offer.

I can tell you now, the same thing that every VC will tell you: working out how to price and package is going to suck. Maybe not as much as SOC2, but it will suck a non-zero amount. You will throw countless pricing models over the wall in your search for an answer, and usage based pricing + Salesbricks is like a great REPL to work in for this period of experimentation.

The more usage data submitted via our APIs, the more options you give whoever is sorting out your pricing and packaging to tune your revenue engine.

And while you're doing so, you're also getting product instrumentation across business segments for free because Salesbricks gives you revenue breakdowns that fold in all the information you're sending.

As your company grows, there are going to be more and more demands on Engineering and Product to make information available and digestible to Sales teams, and it feels great to know that you can write against one set of APIs and be done with it.

Finally, because Salesbricks understands what your team sells, what your customer is doing and how to wrangle the revenue hydra, there's a giant pile of code you and your team no longer have to write. For instance:

Need to enable trials? API Call.

Need to do feature flagging? API Call.

Need to handle subscription management? Believe it or not - API Call.

And there's much more to come.