It's dangerous to go alone, take this!

In today's blog, we’re going to compare the trade-offs between building a metering solution yourself and using a platform like m3ter to accomplish your pricing, metering, and billing needs. 

Because the title may have spoiled the ending, I’ll go ahead and confess that as a strategy and technology leader, I tend to think about these things with a bit of a bias — not necessarily towards buying solutions — but with a bias for time. Every delivery leader in software has to occupy the plane of existence we call reality, and reality has some unfortunate fundamental forces that we all have to live with, namely,

1. there is always more work than can or should be done and
2. there is usually not enough time to do the work in. 

So when I lead software teams I try to think about, and optimize for, capabilities that are the most unique to my company’s product, strategy, or user experience. I want to spend most of my time doing those things, and less of my time doing things that don’t support those elements. With that off the table, let’s take a closer look at why I think “buy” is the right call, now that m3ter exists as a platform for pricing, metering, and invoicing at scale. 

1) Every Engineer You Spend on Metering is an Engineer You Don't Spend on PX/CX

I’ve worked for companies that have bespoke billing solutions supported by large engineering teams who manage the usage and metering of those solutions. I think there sometimes tends to be a false assumption — that by buying a solution you’ll threaten those engineers — when, instead, by giving them a platform that makes delivery easier you open up their ability to do other things. Many folks who work in billing have highly transferable skills because they’re used to querying and presenting data. Maybe your billing engineers build an amazing usage console inside your product now that the work of metering is off their plate, or an awesome forecasting module that projects costs to your customers, or an alerting system that warns about balances and helps scale. You’ll achieve those kinds of experiences faster if you’re not constantly dragging your engineers down by having to tune the fundamentals. Speaking of …

2) Minimum Viable Product is a Gift and a Curse

When you first move to usage-based billing, reality — specifically, that bothersome force of time — is going to intervene. All of us know that there’s a difference between our ideal product and the product we actually ship, and it’s often the case that the assumptions that inform our MVP delivery wind up sticking around a lot longer than we want them to. In practical terms, this starts to look something like never quite having the time to build the pricing heuristic we want for ultimate flexibility, and then being locked into the architecture assumptions we made the first time around for subsequent version updates and changes. Put differently, you might also say “we don’t know what we don’t know.” A company like m3ter who has made pricing their whole core competency will always have to stay on the bleeding edge as an existential problem — their pricing heuristic will almost always exceed a homegrown one in flexibility and scale in order to meet the demands their customers have.

3) Things We Think Are Features Become Bugs Over Time

I’ve seen a billing solution at a post-public company which still required a manual “billing run” executed by a principal engineer. These kinds of problems have innocuous origins: someone decides that billing is critical-path and that usage is high-complexity and so human inspection on the process is a benefit. I’m sure you can see where this is going: fast-forward a few years, and that one human became many, strung together to observe and approve each aspect of their invoice to cash process.

4) At Times, We Choose Less Customer-Friendly or Scalable Options Due to Ease of Implementation or Time Constraints

Here’s an example: have you ever bought software from a company that only bills on the first of the month? It’s certainly easiest from a finance perspective — no partial, unbillable revenue hanging out in the month while waiting for the customer’s next billing anniversary. But it puts all of the strain of billing onto a single day, and leaves customers with short-cycle bills at the start of their experience. Spreading billing anniversaries out allows your engineering team to distribute load, and it lets customers have a predictable billing experience, with anniversaries always on the same day of the month. Here’s another: maybe in order to ship usage-based billing, you deprioritized the usage statements of annual commitment customers in order to make sure everything was ready for the volume of your pay-as-you-go users. I’ve seen companies decide that humans (like a CSM, for instance) can send balances and usage statements to their customers — but I think we all know in our hearts that this process is error-prone and will never be as good as offering that experience directly in product. These are just some of the concepts that m3ter handles out of the box — you don’t have to deprioritize them to save yourself time or resources: they just exist, and you and your customers get to reap the benefits.

5) Going at It Alone Will Extend Your Time to Market and Make Managing Packaging Harder

In my next blog, I’ll describe how a m3ter implementation can be accomplished in just six weeks with a fairly robust and scalable first version — from product events all the way to integrations into payment platforms and CRM. It would be virtually impossible to accomplish the same speed (using the same resources) without an effective, low-code platform handling calculations and streamlining integrations — taking care of the fundamentals so that your resources can focus on what’s truly unique to your business.  m3ter is also built to handle an array of pricing, plan, and discount complexity, making it easier for you to offer flexible packaging without sacrificing on time, reliability, or accuracy.

6) Silos Persist in Homegrown Solutions

One of the things I was most excited about when I implemented m3ter was the way it broke down silos I’ve always experienced: product teams usually aren’t that exposed to the needs of finance teams, sales teams often have a hard time getting or understanding product usage data. Because of the limits of time and resource, homegrown solutions tend to support only the basic needs of any departments who might also have an interest in usage or billing data — they’re sort of second class citizens by necessity. m3ter integrates easily to CRM, ERP, and payment solutions, and has two-way APIs that can extract its intelligence into your data warehouse. This immediately democratized something that I had been asking for — and unable to get — for years. Some of my later blogs will touch on how this can unlock new and powerful capabilities for your business, but I genuinely think it’s one of the most exciting aspects of this software.

7) Revenue Recognition is Easier with m3ter

Because m3ter cares about pricing, packaging, metering and billing as a holistic solution, it has ready integrations that can easily bring usage into your ERP. Even on a dynamic billing anniversary, grabbing the usage for a particular month is as simple as taking a snapshot of m3ter’s usage output at the end of the billing period and recording it downstream. Even if there’s further complexity in your company’s revenue policies, m3ter immediately offers one clean, simple input, which can drastically reduce the difficulty of implementing other revenue solutions. And automating these feeds instead of implementing manual, human-driven, error-prone processes improves accuracy and repeatability — two things that can really help a team advance its maturity in the areas of audit and compliance. 

I know the counter-arguments, too: nobody knows our business as well as we do, and so we need this capability in-house is perhaps the most relevant reason for choosing to build in this scenario, especially now that several viable solutions exist in the market. But we are all now using software to solve problems people used to say this about until something robust, scalable, and democratizing came along — platforms that let us market to our users, sell to our prospects, support and train our customers — all capabilities that have not become any less critical to our businesses simply because we bought tools to accomplish them. And we’ve seen platforms like Zapier and Workato take a difficult problem, like integrations, and democratize it for users to create automations in clicks, not code. 

Like I said before, for me it tends to come down to how can I invest in a way that supports my company’s most strategic priorities scalably and responsibly? m3ter takes what used to be a fairly abstract concept, pricing and packaging, and turns it into a platform for developers and operations teams alike without sacrificing on flexibility, scale, or speed. 

I once attended an agile workshop where the speaker argued for the concept of a Minimum Lovable Product, instead of a Minimum Viable Product — something I think we can all agree on in theory, but which can be hard to execute on in practice. 

With m3ter, you don’t have to make that choice.