draft

vim ./src/drafts/pricing-engine-vs-billing-engine.md

Pricing Engine vs Billing Engine

One lesson we've learned talking to companies on their pricing journeys (and from our own in the past), which is implicit in a sound PriceOps strategy, is the importance of separating the concepts of "Billing Engine" and "Pricing Engine".

It's one of those things that feels obvious when you see it, but until you do, it can be hard to grasp why it's important. The result, all too often, is that we end up with the wrong abstraction trying to do double-duty.

Just as you probably wouldn't use a relational database as a message bus or vice versa, mixing these concepts can spell disaster.

The Problem

All too often, companies approach their pricing implementation in the following way:

  1. Choose a billing engine (Stripe, Lago, etc.)
  2. Have a bunch of meetings where they argue about the best pricing model (and hopefully write it down somewhere!)
  3. Configure the billing engine with the model they decided on (or realize it's too complicated, and go back to step 2).
  4. Store all the information that the billing engine needs in their application database (identifiers for prices, products, customer IDs associated for each user, etc.), and add the required reporting logic in the application in the appropriate places.
  5. Pray that no one ever has to touch it again. (Or failing that, that you've got a new job somewhere else before that happens.)

Where does the pricing model live? As it happens, it's smeared across a variety of loosely connected components, some of which store it as implicit assumptions.

Billing Engine vs Pricing Engine

The insight is that a lot of value can be unlocked by separating these two abstractions.

A Billing Engine is the component in the stack that bills customers. It's "one job" is to send an invoice at the right time, in the right amount, to the right buyer.

In order to do this, it needs to know some information about the customer, what thing they bought, the price they should be charged for it, and in the case of metered billing, the amount of that thing that they consumed.

A Pricing Engine is the component in the stack that manages and implements the pricing model. You can think of it as "the thing that does PriceOps". It knows what the various pricing plans are, where they live in the Billing Engine, and thus can present a clean API surface for application code to create subscriptions and report usage.

In order to do its job (and prevent other components from trying to take over!) it needs to store the pricing model itself, and present a clean abstraction to the application code, billing engine, and all other technical and business components that need access to price information.

And perhaps most importantly, it must support making changes to the pricing model, without its abstractions leaking out to consumers.

Benefits

The most tangible immediate benefit of a comprehensive Pricing Engine is that it can simplify the process of setting up a Billing Engine, and reduce the amount of billing-related metadata that needs to be tracked and managed by application code.

While this is enough of a reason to use it, it doesn't always feel like a huge win. Integrating with a whole new component in the stack feels like adding complexity in one place in order to maybe save it elsewhere. Even if it makes your code cleaner and simpler, it's not that bad, right? Isn't "having too many customers and complicated deals" sort of a problem I can worry about when I'm rich and successful?

However, the trouble with this line of thinking (which all of us at Tier have learned through painful expensive experience) is that it can be very difficult for a company to become successful if they cannot easily iterate on their approach to pricing and packaging.

Streamlining pricing with a comprehensive Pricing Engine lets everyone focus on their specialty. This unlocks growth that would otherwise be lost in inefficient processes.

Why We Made Tier

What we've found is that the most experienced and insightful practitioners in this space follow exactly this kind of approach. That's how the concept of PriceOps was born.

Tier is a comprehensive Pricing Engine, which drives your billing engine and application code from a single source of pricing model truth, so that everything in your company can work in concert, even as your business changes and grows.

drafts