Building the future of billing: Why I joined Metronome

Oct 31, 2022
 • 
0 MIN READ
Gold share tray icon
Suyog Rao
Head of Engineering
Get updates into your inbox
Sample Metronome billing dashboard
Share

I joined Metronome as the Head of Engineering a month ago and it's been an exciting start to my journey! As I continue to jump headfirst with the team, I wanted to first take some time to share my perspective on why I joined Metronome and why I’m so excited on what we’re building here.

As a quick overview, Metronome’s mission is to help software companies launch, iterate, and scale their business models with billing infrastructure that works at any size and stage of your company’s growth.

How my background led me here

Before Metronome, I spent 8 incredible years at Elastic, where I was fortunate to be part of its growth from a popular open-source startup to a multi-product, public company.

Most recently at Elastic, I led an engineering organization that was critical to Elastic’s success on Cloud. My team was responsible for data ingestion, monetization, growth, and internal analytics. One of my highlights at Elastic was being part of a cross-functional leadership team that led the transition of the company's business model from a self-managed enterprise sales motion to a consumption-based Cloud service.

Experiencing firsthand how hard usage-based billing is

At Elastic, to achieve our strategic goal of transitioning to a fully cloud-based revenue model, our team had to create a scalable, real-time, usage-based billing engine from the ground up. It took us many years of intense development efforts involving a large engineering team across multiple timezones. Today, what we built handles all of Elastic’s Cloud revenue — several 100s of millions in ARR — and multiple go-to-market motions including pay-as-you-go, direct sales, and AWS, Azure, and GCP marketplace channels.

While it was fascinating to build a billing engine from scratch, I always thought that Elastic would have benefitted greatly if a billing platform like Metronome existed.

I joke that there are only two hard things in computer science: billing and naming things.

At the core of it, usage-billing is a high-volume data collection and processing problem with strict constraints on correctness, resiliency, and low latency. Implementing these constraints at scale is really tricky. Now add to it the requirements of being flexible, ensuring financial compliance, self-service, and connectivity to internal business workflows. Phew!

At Elastic, at various points in our journey, we had internal discussions about building vs. buying a billing engine. When I initially did our vendor research in 2018, there weren’t a lot of options. Existing billing companies were architected for a world of recurring subscriptions. They have significant product gaps and don’t have the data platform to scale for newer high-volume, usage-based models that power infrastructure SaaS companies like Elastic, MongoDB, and Confluent.

So, why Metronome?

When Metronome publicly launched earlier this year, I heard about them through a SaaS community that I was part of. Having just built a successful internal billing engine for Elastic replete with battle scars, Metronome’s product immediately caught my attention. In my conversations with Scott, Metronome’s co-founder and CTO, it was evident that the product was 1) built intentionally to scale for high-volume usage data in a multi-tenant environment, 2) designed with a developer-first lens, and 3) integrated with all the business workflows and business models an organization had - no easy feat!

In Metronome’s vision, I saw a once-in-a-lifetime opportunity to create a modern billing platform minted in the Cloud and SaaS world that every company, small and large, would need and use.

This was already being validated by several household infrastructure and SaaS companies like Cockroach Labs, Cribl, OpenAI, and Starburst who had successfully launched their products on Metronome’s billing software. Software companies are increasingly moving to usage-based pricing models due to the principle that if more value users get from the product, they will consume more, and they will pay more and grow their usage over time. This shift presents an enormous opportunity for Metronome to enable companies in every industry with this transition.

Scott and Kevin have built a talented and diverse engineering team with folks who’ve worked at startups and larger companies like Dropbox, New Relic, Google, Plaid, and Pinterest. Building a software company that is the system of record for revenue and growth is not going to be an easy task. To help us get there, we have a great foundational team, and a culture that is rooted in the values of ownership, scrappiness, growth mindset, and pragmatism. I am fortunate to be joining a team that is intentional about investing for the long term, while still delivering iterative value. We have a strong written culture, care for each other, and have fun (virtual and in-person!).

photo of metronome team in a recent offsite
Some of Metronome's team in a recent offsite

Come join us

If you want to solve hard engineering and business problems and are passionate about building impactful solutions, then come join us as we build a real-time source of truth for business data.

Company Industry Outcome-Based Pricing Model Key Metrics for Pricing Notable Features
Salesforce (Agentforce) CRM / AI Customer Service

$2 per conversation handled by Agentforce (AI agent)

A conversation is defined as when a customer sends at least one message or selects at least one menu option or choice other than the End Chat button within a 24-hour period.

Number of support conversations handled by the AI agent

First major CRM to adopt a "semi"outcome-based pricing for AI; aligns cost with actual support volumes (clear ROI)

Addresses inefficiencies of idle licenses by charging only when value (a handled conversation) is delivered

Intercom (Fin AI) Customer Support Software

$0.99 per successful resolution by "Fin" AI chatbot - clients pay only when the bot successfully resolves a customer query

Fees accrue based on AI-solved issues

Count of support conversations resolved by the AI agent

Early adopter of AI outcome-based pricing in 2023

Lowers adoption risk by charging for resolved queries instead of a flat rate; combines usage- and value-based pricing to tie cost directly to support effectiveness.

Zendesk (AI Answer Bot) Customer Support

Per successful AI chatbot-handled resolution

No charge if the bot fails and a human must step in

Number of customer issues or tickets auto-resolved by the bot

Aimed at cost-conscious customers wary of paying for unproven AI

Aligns price with realized automation benefit; part of a broader industry shift from per-agent pricing to value-delivered pricing in support

Chargeflow Fintech (Chargeback Management)

Charges a fraction of recovered funds on chargebacks

Example: ~25% fee per successful chargeback recovery

No fees for chargebacks lost

Alert service charges $39 per prevented chargeback

Value/count of chargebacks recovered (disputes won) and chargebacks prevented (for prevention alerts)

4× ROI guarantee on recoveries

No contracts or monthly fees

Revenue comes only from successful outcomes; pricing directly aligns with merchant's regained revenue, meaning Chargeflow only profits when the client does (win-win model)

Riskified*

(source: https://www.chargeflow.io/blog/riskified-vs-forter)

E-commerce Fraud Prevention

remain fraud-free

PAYGO, 0.4% per transaction

Only charges for transactions it approves that

Number or value of approved transactions without fraud (i.e. successfully processed legitimate sales).

Provider shares financial risk of fraud with clients; pricing tied to outcome of increased safe sales

Incentivizes vendor to maintain high accuracy (they only profit when fraud is stopped)

Foster continuous improvement in their fraud-detection algorithms

Subscribe

Keep up with the latest in
pricing and packaging