An engineering leader's perspective on Cloud GTM with Suyog Rao, Metronome

Trunal Bhanse: All right, super excited for our next episode here on the Clazar Podcast. We have a very special guest, someone I’ve known for the past couple of years and a noted engineering veteran in the industry. I’m so happy to have you on board. Why don’t you introduce yourself to the audience?

Suyog Rao: Yeah, thanks for having me. We’ve been playing calendar tag for too long, so it’s great to be here. My name is Suyog. I am the Head of Engineering for Metronome, a billing-as-a-service software company. Our mission is to operationalize and accelerate software revenue. We believe billing is at the heart of every SaaS company, and a key part of success isn’t just building a great product but also pricing it effectively and taking it to market, which I know we’ll discuss a lot today. Billing plays a huge role in that.

Metronome provides a platform that enables companies to create usage-based billing models, take products to market, and actually invoice and bill customers. We’re doing this so companies don’t have to build these capabilities from scratch. I’ve been down that road myself back at Elastic, so I’m happy to share those experiences. Over the past year, we’ve seen a lot of traction. We recently raised a $43 million Series B from NEA and are working with fast-moving companies like OpenAI, Anthropic, and Databricks. It’s been an exciting time to collaborate with those companies and stay in sync with their rapid pace.

Trunal: Fantastic, fantastic! And again, congratulations on the funding round. I just saw that announcement the other day. Super excited for both you and Kevin! So, let’s dive a bit deeper into your background and the billing space. I know you did a lot of work in this area at Elastic as well. Can you share what that experience was like? And specifically, why is usage-based billing—UVB, as we call it—so challenging? Tell us a bit more about that.

Suyog: Yeah, I spent about eight years at Elastic. I joined fairly early on and saw the company go through major transformations. We started as an open-source software company, then transitioned to a self-managed, subscription-based model, which included support and professional services. Eventually, we became a multi-product company and went all-in on the cloud, just like many companies that started in the 2010s realized was the future. We invested heavily in that transformation, and it was a critical milestone in Elastic’s history.

I had a front-row seat to this shift because I led one of the cloud platform teams, and a part of my team was tasked with building the billing software. Back in 2017, we looked around and didn’t find much in terms of out-of-the-box, enterprise-ready billing software. So, we decided to build it ourselves, just like many peer companies such as Mongo and Confluent did. It was a fantastic experience—not just the technical aspects of building the system, but also understanding the go-to-market side of it.

I describe usage-based billing as an octopus with tentacles reaching into different parts of the organization, which is what makes it so complex. One thing I’d like to clarify is that while many people don’t fully understand usage-based billing, they actually encounter it all the time. You see it with Amazon or other infrastructure providers, but it’s not something you notice until you really pay attention. You get an invoice, pay it, and that’s it.

The analogy I like to use is that billing has traditionally been subscription-based—you pay a recurring fee every month or year. Usage-based billing, however, is the opposite; you pay only for what you use. For example, if you consume more S3 storage from Amazon, you’re only billed for that additional usage. A similar analogy is Netflix: you pay around $13 a month, whether you watch or not. Imagine if Netflix were usage-based; you’d only pay for the actual time you watch.

Trunal: That’s not usage-based. Subscription, yeah?

Suyog: No, exactly, that’s subscription-based. So the key difference here is that, as a consumer, I’d love to pay only for the value I get. If I watch just a few movies here and there, I’d pay only for those. That’s the essence of usage-based billing—you pay for what you use, and the value you get becomes the most critical part. Instead of a flat $15 every month, you’d pay based on actual usage.

Imagine if Netflix charged per movie or per hour watched. This shift is transformational, especially for companies like Elastic and Confluent. A lot of infrastructure companies building on platforms like AWS, GCP, and Azure need to price their offerings while factoring in their infrastructure costs. For example, Elastic buys infrastructure from these clouds, so we have to price our offerings in a way that maintains our margins while reflecting the actual costs and aligning with how customers use the product. That’s why usage-based billing is becoming so popular.

It’s challenging, though. One reason is that, unlike straightforward subscription billing—where you just run a recurring monthly charge—usage-based billing requires constant data on actual consumption. Using the Netflix example, if Netflix were usage-based, they’d need data on hours watched, types of movies, pauses, and more. You’d measure all those metrics, aggregate them at the end of the month, and then join them with pricing information. This includes applying any discounts or contractual agreements before sending the final invoice.

So it’s fundamentally different from subscription billing and more like a data platform. You’re constantly capturing high volumes of product metrics—how customers interact with your software—and then joining it with contractual details. That’s what makes it complex.

Another challenge is that as cloud go-to-market models have shifted toward usage-based billing, every stakeholder needs access to this data. It’s not just about invoicing; you also need granular data that’s often hard to capture and even harder to democratize. So, it’s also a core data problem.

And then, returning to the octopus analogy: each team needs specific insights. Finance wants to track revenue to see if monthly targets are being met. Sales operations need data to understand how sellers are being compensated—sometimes even based on product consumption, which is great for aligning value creation with sales. Engineering needs to integrate the metrics from the product, while product management adjusts pricing, tests new models, and experiments.

Analytics teams, revenue recognition, and many other functions all rely on this data to drive their processes.

So, it’s a complex puzzle. That’s where Metronome comes in. Our approach is to provide an out-of-the-box solution that integrates with existing tech stacks, from code to cash, like Salesforce, through to NetSuite. That’s why Metronome has seen success over the past few years.

Trunal: That is fantastic. And when you think about the different pieces and components, right? You touched on many aspects—one being the go-to-market side, where finance teams need information, and so on. But as an engineering leader, I’m very interested in understanding how you’d advise companies considering a shift to usage-based billing. Let’s say there’s a company out there today that may or may not be using usage-based billing but is considering it. From an engineering standpoint, could you guide them on how to approach this? Should they consider a solution like Metronome from day one, or should they build something custom and then wait for a critical inflection point before making the switch? How would you guide them?

Suyog: That’s a great question. About five to ten years ago, the software for usage-based billing was very proprietary; it was almost like a “secret sauce.” Snowflake was a poster child of consumption-based billing, following AWS’s lead. Then companies like Confluent, MongoDB, and Elastic started doing it too. At the time, having this pricing model was a kind of moat, and powering it required custom logic and specialized infrastructure.

Fast forward to 2024, and this software has become commoditized. Today, nearly every infrastructure SaaS company is in this space, and AI companies are charging based on metrics like the number of API calls. So, given the current landscape, you don’t have to build it all from scratch. Focus on what you want to do for your company—whether it’s building the best database, analytics software, or AI solution. Don’t worry about billing; it’s something you can outsource, allowing you to focus more on your core product.

The last two years have reinforced this trend, especially in this economic environment where companies are running lean and engineers are seen as a sacred resource. It’s not like 2016, when over-hiring was common. So, the question becomes: do you want your engineers working on a billing engine, or do you want them building the best database in the world? That’s how I look at it. In short, if you know you want to adopt usage-based billing, you should go for software that does it well. It has matured significantly and is now largely commoditized.

Trunal: As someone who has led billing teams, I totally agree. Those battle scars, for sure! I’m completely aligned with you on this. Now, shifting back to our engineering team—engineers do have this tendency, right? When it comes to build versus buy, we often just want to build everything ourselves instead of buying.

Trunal: So, as an engineering leader, let’s say you were on the other side and Metronome was trying to sell to an engineering leader who is inclined to build the solution themselves. Of course, there are always some customizations and unique requirements that a platform might not provide. How would you approach that conversation? What would you tell them as they’re considering this decision?

Suyog: Yeah, I’ve been part of a lot of sales cycles here at Metronome, and we’ve definitely encountered this argument: “We’ll build it ourselves.” Often, this stems from a cultural tendency to build rather than buy. Our approach is to share examples of companies that initially tried to build it. I come from a background where Elastic built its own solution, and we thought, “We have some of the best engineers—how hard could it be?” But it turned out to be quite challenging and required constant effort to keep it running smoothly.

In many cases, we use referenceable customers to highlight the complexity. And honestly, if someone is determined to build it themselves, we’re open to advising on the approach—almost like, “Go ahead, give it a try.” Many companies start building it but eventually realize it’s not sustainable as they scale. There are often conflicting voices: product managers want fast releases and pricing flexibility, engineers are confident they can build it, and then finance jumps in and asks for revenue forecasting or RevRec. And the engineers are like, “Wait, what’s RevRec?”

We help them understand the many “tentacles” a billing engine has across the organization. This often becomes a clarifying moment when they realize it’s not just a straightforward piece of software; it demands a lot of maintenance and attention. That’s usually a turning point. Sometimes, they still try to build it and come back later, which is also fine.

Trunal: Okay, that was fantastic, Suyog. Now let’s switch gears a bit from billing to your experience with cloud marketplaces. I remember that’s actually how we initially connected, back at that cafe in Mountain View.

These two worlds—billing and cloud marketplaces—are quite related in many ways. AWS, Azure, and GCP marketplaces have their own metering components, which align closely with what usage-based billing providers like Metronome are doing. Based on your experience, how has your engagement been with cloud marketplaces, and is there anything you can share about how they impact the billing side?

Suyog: Sure, let’s look at the cloud go-to-market approach as a whole. There are multiple channels for selling your product. First, there’s the direct model—you go to a website, call a salesperson, and buy the software directly.

Then there’s the pay-as-you-go model, where users don’t commit long-term but use the software on a monthly basis. Lastly, we have cloud marketplaces, where you can purchase software through platforms like AWS, GCP, and Azure.

I was exposed to all of this while working at Elastic. As an engineer, I initially had no idea these options existed—I was oblivious. My focus was building the product, and I just cared about seeing the revenue grow. But then my boss told me about a project to transform to a consumption-based model, which included cloud marketplaces. At first, I resisted, thinking it wasn’t interesting, but I was wrong. There’s a huge amount happening in this space, and engineering plays a significant role.

I've noticed two major shifts. First is the growth of data warehouses; data is king. Usage-based billing, and cloud marketplaces—these models generate a wealth of data on how people consume your product. But that’s only the beginning. You also have sales data, financial data, and information on customer acquisition. Data warehouses bring all of this together, allowing teams across the organization to analyze it. In many companies, data warehouses start with engineering and then transition to IT and analytics teams, but the central theme is that everything is data-driven.

The shift to cloud fundamentally changed sales. With cloud, you have high-volume sales and access to metrics that weren’t available with on-premise software. You can see product usage data, and even though it’s anonymized and privacy-compliant, it’s incredibly valuable. Product teams, finance, marketing—all of them can use this data to understand customer acquisition and usage patterns.

Getting exposed to this world was eye-opening. It’s fascinating how critical this data is to a company’s revenue and how it feeds into what gets reported to Wall Street. And then, with cloud marketplaces specifically, what I didn’t initially realize was…

In many companies, data warehouses are initially owned by engineering and then transition to IT or analytics teams. But in this whole cloud go-to-market landscape, the primary change has been a shift towards a data-driven approach. It’s all about data, especially because you’re dealing with high-volume sales. Selling through the cloud is very different from on-premise, where you don’t have as much access to usage metrics. With cloud, while maintaining privacy, you get insights into how customers actually use the product. This is valuable for everyone—from product to finance to marketing—to understand targets and customer acquisition.

Being exposed to this world was fascinating. As an engineer, I realized how critical this data is to a company’s revenue and even to reporting back to Wall Street.

Now, back to cloud marketplaces. Something I didn’t initially realize is the scale of spending that companies invest in cloud providers. For example, in Airbnb’s S-1 filing, they disclosed a significant AWS bill. This commitment is powerful because it doesn’t just support native apps within the cloud but also provides a frictionless way to buy software through the marketplace.

This ease of use is huge; you want customers to be able to provision software without hurdles and easily send usage data back. When we built out our marketplace offering, we collaborated closely with AWS, GCP, and Azure, and it was fascinating to watch our growth curve with cloud marketplaces—almost like a hockey stick. At one point, we wondered if it might even eclipse our direct sales.

Personally, I think that in the next decade, cloud marketplaces will become the primary way people buy software. From an engineering perspective, it’s about understanding that we’re users of cloud platforms ourselves. We know firsthand how convenient it is to use AWS or any other provider—just a few clicks, and you have the software you need without going through finance approvals. That convenience is the mindset you need when building these integrations, and it’s been transformative in how software is sold.

Trunal: Absolutely, and of course, I might be biased, but I agree that in the next 10 years, a majority of software transactions will happen through marketplaces. You can already see it—companies like CrowdStrike have announced they’ve generated a billion dollars in revenue just through AWS Marketplace. Other companies have reported similar successes, and it’s becoming the norm. The first entry is always the hardest; it takes longer and faces more challenges. But once it’s established, others follow, and I’m very excited about the future.

Suyog: Right, and for the consumer, the buying experience is incredibly easy too. You remove all the friction, which is huge. That’s exactly what every product manager and engineer wants—quick access to the product.

Trunal: Yeah, exactly. Funny story—I have a founder friend who was looking to buy some software for his startup. He visited the company’s website, but they had a lengthy sales process with “contact sales” as the only option. He just wanted to buy one seat, nothing complicated. So he went to AWS Marketplace, found the software with a simpler integration option, clicked once, and was done. He was amazed and said, “I had no idea this was possible!”

Suyog: Yeah, it’s pretty powerful, right?

Trunal: Very powerful. So, thinking about engineering and integrations—knowing what you know now—if you had to start over, would you invest core engineering resources into marketplace integrations, building analytics, and everything from scratch? Or would you recommend getting help from vendors like Clazar or others? In short, would you build or buy?

Suyog: Much like with usage-based billing, I’d say four or five years ago, marketplaces were pretty exclusive. You had to be invited, and AWS, GCP, and Azure maintained very selective relationships with certain vendors. But now, there’s a lot of co-selling and joint go-to-market efforts. The marketplaces themselves recognize the value of strong vendor partnerships and aim to simplify buying through the marketplace. As a vendor, you don’t want to spend all your time building the machinery to enable marketplace transactions.

Just like usage-based billing, you’d need to handle various APIs across different marketplaces and manage private offers if you’re an enterprise. It sounds straightforward, but the details are complex and require significant effort. So the question becomes, what do you want your engineers to focus on? Are you building the best software your company is known for, or are you investing in being the best at marketplace integrations? What’s the actual value to your company?

These days, it’s much more practical to choose vendors who can help with integrations. We’ve seen this trend at Metronome, too. What’s interesting now is that even smaller companies with less than $5 million in revenue are adopting multi-channel strategies, going all-in on marketplaces and direct sales. It’s happening because these integrations are now more accessible, and smaller companies don’t have the engineering resources to build and maintain these platforms themselves.

It’s been a revelation to see not only large companies but also smaller ones embracing this multi-channel approach, which is great.

Trunal: Absolutely. And just to add to that, we’re seeing exactly that trend. On our platform, we have large and small companies alike. Month over month, quarter over quarter, we’re seeing the point at which companies consider marketplaces shift closer and earlier in their journey. The big cloud providers are pushing this hard with extensive resources, go-to-market support, and even financial backing. The barrier to entry that you and I experienced is largely gone, and it’s now much easier for companies to get started. If you’re a startup, it’s cost-effective and creates leverage. So, in today’s world, it makes complete sense to start on the marketplace.

Last question from me: you’re at Metronome, deeply involved in the shift toward usage-based billing. Fast forward three, five, even ten years—where do you see usage-based billing heading? And could you add some insight on how marketplaces may play a role in that future?

Suyog: Absolutely. One of our core beliefs is that every software company will become a SaaS company, and every SaaS company will have a component of usage-based billing—whether they fully embrace it or combine it with other models like per-seat pricing. That’s the future because it allows companies to show value directly to their users. Going back to my Netflix analogy, it’s about paying based on the value you get. Consumption-based models create a flywheel: if users get more value, they use more and pay more. This approach is driving a lot of software sales today.

I think we’ll see more hybrid models that blend subscription and usage-based elements, as well as purely usage-based models. For example, many AI companies like OpenAI and Anthropic are adopting usage-based billing because a significant part of their cost is infrastructure, specifically GPUs. They need to price their products in a way that reflects those underlying costs.

This shift to usage-based billing is becoming more prevalent. A recent example is a company in the chatbot space that moved to a usage model, charging per message or interaction. Companies are getting creative; even if they start with a subscription, they may gradually introduce a usage component to increase value for their customers.

Once you recognize usage-based billing, you start seeing it everywhere. Think about Uber: you start the trip, that’s the marker, and when you get out, that’s the end of the usage. You’re billed based on that trip, not a subscription. We’ll see more industries and sectors embracing this model.

And as for marketplaces, they’re tightly connected to this shift. When you pay AWS for cloud usage, it’s entirely usage-based. So, if you want your software to feel as native as possible within the marketplace, you need to provide that experience. When I was at Elastic, we worked on a native integration with Azure that allowed one-click data transfer from Azure Kubernetes to Elastic, and the marketplace experience was seamless.

This native feel is where I see things going—every software will be closely embedded within cloud providers. It’s beneficial for everyone: customers avoid upfront costs, and the experience is frictionless.

Trunal: Absolutely, and what you said really resonates. We’ve often said that usage-based billing is the most ethical business model. You charge the customer based on the work you’ve done, with a margin on top, and there’s transparency on both sides. Customers know exactly what they’re paying for, and they can adjust usage based on their needs. It’s a clean, straightforward model for founders and business owners.

Thank you so much for coming here and sharing your thoughts, Suyog. This was fantastic, and I look forward to working with you for years to come.

‍Suyog: Thanks, Trunal. It’s been a pleasure. Good luck with Clazar!