The Infra Pod - Billing is a infrastructure problem, and it's shifting fast! Chat with Alvaro from Orb

Episode Date: January 30, 2024

Ian and Tim sat down with Alvaro (CEO of Orb) about how he dived into the Billing problem as a engineer, and now building a company Orb that's powering a developer facing infra for Billing. Come join our discussions to talk about how Billing has evolved, why it's a infra problem, and how having a infra powers billing and everything around it for companies to move much faster than before.

Welcome back to yet another Infra Deep Dive podcast. This is Tim from Essence VC. And Ian, let's go. This is Ian, working at Snyk, making it platformy, you know, all the good stuff. And I'm super excited to be joined by Alvaro, who has started a cool company in the billing space. Why don't you tell us about yourself and your company? Absolutely excited to be joined by Alvaro, who has started a cool company in the billing space. Why don't you tell us about yourself and your company?

Absolutely excited to be here. So I'm the co-founder and CEO at Orb, and we are a flexible billing engine that's purpose-built for what I call modern pricing models and software. So everything from usage-based billing to more hybrid pricing, starting to evolve from the core seats model to more consumption type oriented models. That's really what the use case that we are built to support. And we power billing for customers like Rassel, Replit, Materialize, across all sorts of business models.

So you see a lot of presence in cloud infra, fintech, data, and increasingly AI. I think the value prop is simple. It's why spend your engineering time on billing infra when you could spend it on building out your core product. So that's why we built billing for you and you can leverage Orb to achieve those goals. The big insight from starting the company came from the experience that my co-founder and I had at Asana, where we were there on the engineering team. We were part of a major growth phase in the company and we got to see pricing changes happen over and over again. And each time they had

this interesting property of being immensely ROI positive and valuable for the business, coupled with incredibly painful for every single human involved in the process. The core insight there was just this massive opportunity to decouple business logic from being riddled all over code bases and actually give folks a control plane for their monetization. And that essence of this developer platform lens approach to billing is what has grown into what Orb is today. Amazing.

And so let's just get started. Why do we care about usage-based billing? If you think about 2003, or actually whenever the Salesforce IPO happened, I think it was actually a little later than that, CRM comes on the block, seat-based billing is here, SaaS is the future.

It might have took another decade before we actually had SaaS as the future, but CRM certainly and Salesforce certainly being the first to go from SaaS to IPO. What is it about usage-based billing, and why are we going after usage-based billing when the traditional model for SaaS applications has been seat-based? What's the thought process behind it? Why do we care about usage-based billing?

That's a great question. And I think there's a little bit of like, we care about usage-based billing because we're seeing the force of gravity at play and how it's starting to affect and influence business models across a bunch of companies. I think the modern buyer has realized, why should I pay for this gym-like seat subscription that I never use in shelfware software when I could actually pay for it in a more truly usage-based aligned way?

What am I actually consuming? What value am I getting out of the software? And why should I need to pay for any additional lock-in? Now, the reason why we're here is because of our ability to much more granularly meter and track usage across a wide range of applications. So what I find fascinating is the advent of cloud led to the seat-based business model, but the proliferation of cloud is actually what's giving way for more usage-based models, where at every level of the value chain in the software delivery model, you get the opportunity to partner with all these vendors that are providing very measurable services. And you get to have sort of this composable usage-based value chain that why would you not price in a way that's optimizing for flexibility and fine granularity? Now, I'm giving you the consumer perspective, but the reason why businesses and vendors care about usage-based billing in 2023 is a combination of opportunity and necessity.

Opportunity from the perspective of like, there's rapid product innovation, I'm launching new product lines, I'm starting to think about how I can integrate AI into my product offering. Of course, the core value metric or the core pricing model has to evolve. Obviously, this has been a very challenging year in the macro environment. And it doesn't matter how fantastic your product is, if your customer is doing a riff and laying off half their workforce, they're going to inevitably want to contract their agreement and downsize. So I think what's interesting is that what's propelling this forward is very much this combo of opportunity and necessity. That makes a lot of sense. One of the questions I finally have about usage-based billing, the shift to usage-based billing, is there are specific types of companies or products where usage-based billing makes a lot of sense versus a seat-based?

And there's also sometimes transition. So in one case, is usage-based billing just like the de facto, this is accepted form. Where is it novel? And then I've also witnessed this transition over a period of time from seat-based to usage-based. I'm curious your thoughts and perspectives on why that has occurred. That's a really good breakdown because I guess from the outset, and maybe this is a little bit controversial to say as the founder of Orb, but usage-based pricing is not a silver bullet that is correct for every single business out there. I'm not one to get on a stage and say like, the seat is dead. Everybody's going sort of this way. I think it's important to highlight the core product-specific, software-specific reasons why your service could and should be monetized in a usage-based way.

Just to go in a little bit of a tangent here, that's actually what drew me into this world as an engineer. When I was early in my career at Asana, I remember I got pulled in to help an upcoming pricing change. And I have to say, I was internally rolling my eyes a little bit. I'm like, oh, okay, fine. I'll go help out here. I'm probably going to see a bunch of spreadsheet models and a bunch of financial analysis, whatever, write two lines of code and move on with my life. I think what I actually found is that pricing is an incredibly product-centric and customer-centric discipline. And it's like a whole exercise of trade-offs left and right

in terms of what's right for my customer, what's right for the target markets I want to my customer, what's right for the target markets I want to grow into, what's right for the product feature we're specifically launching. So if anything, I think a thing that's often misunderstood about pricing is that there is no silver bullet single best model for companies. So back to your question there of who is this right for? Well, if you're offering a team-aligned, collaborative-based type value product,

of course the seat's right for you. The more you can engage and grow inside of these teams, the more you can show by proxy, my product is doing its job. But I think where the true innovation is happening is the closer where we can align pricing to outcomes. And Intercom took an amazing first step in this direction earlier in the year.

I don't know if y'all saw this. They launched their FIN product, of which there are now some 101 billboards showing how they're actually able to close out and answer some of your support tickets through them. But their pricing is actually aligned on like, did the customer self-report that their support case was successfully resolved? That's as close as you can get to truly driving an outcome, which gets me so excited because there are ways in which you can think about new functionality being created

that aligns more naturally in usage-based monetization. I think the smartest companies out there are not being dogmatic about what's the latest pricing trend and much more thoughtful and nuanced about what in my product enables this to be effective. So I guess the question here is typically when we associate usage-based

means almost like Amazon credits or billing, like I've used that much CPU, I used that much time and build accordingly, is not truly outcome-based, but it's definitely easier for people to think about. If I'm going to rent something for an amount of hours, and I'm probably going to rent this only for a certain time, I can either start really simple, one team, one engineer, play around with this and grow upwards and stuff like that. But now you mentioned this sort of outcome base is definitely where I see a lot of enterprise

products when they grow up more. They want to be able to align with that because you have a lot more ways to convince why I'm spending this much more money. Is there a way to align outcomes possibly with usage at all? It's both the closest proxy to an outcome and often like, not to get too mathematical on this, but you can imagine like a price point value curve where like value is some sort of like the true ROI of a solution that's a little bit fuzzy to measure. And then the pricing model is like the closest approximation that you're getting towards it. And usage-based maybe is as close as you can

get towards approximating that real value curve. But I think there's some just really interesting examples of companies doing this well. Zapier is a great example. Think of it, the more value that your organization gets out of Zapier, the less people that maybe need to log in to zapier.com or the less people that actually need to know that there is an automation layer running in the background. So in some sense, the outcome that they are achieving is automation so your workforce doesn't have to care with this. And the way that they measure it is through ZapRuns, which is sort of a close proxy to how much like, how many road to tasks are

you automating that otherwise would have required a human. So even though a lot of true consumption originated from AWS and then taking a step back, like electrical utilities, we're starting to see those primitives be defined in a product-specific context across different providers. Cool. I'd like to dig in. Why have we seen companies like CircleCI, this is one that comes to my mind in terms of credit model, why have we seen these companies go towards a credit model? What's the thinking behind this? And why is this fundamentally different and better for both the customer and the business than a traditional seed-based model?

I love this question. And I love this use case because we're actually with Orb powering this specific use case for a lot of AI companies that are thinking the same wavelength. We were talking before about how there are some upsides to having a usage-based model

compared to a seat-based model. There are clear downsides. And one of the clearest downside as an enterprise vendor is that it is way harder to get a usage-based model through a procurement department. Because ultimately, there has to be a CFO somewhere that is approving a budget line item.

And if you have a thing that's inherently variable, it begs the question, wait, how big is this check that I'm signing for? So I think credits are a fantastic tool for companies to sort of address this downside of usage-based model, which is the lack of predictability in spend and the difficulty in budgeting. So at its simplest form, what it does is it lets you pre-buy a wallet or amount of credits, and you're saying, great, I'm committing to $50,000 in

annual spend and let's see how I draw them down. I'm able to kind of make some projections, maybe get some help with the vendor sales team, but ultimately I'm signing a check for an amount of money that I can put in my P&L and budget and all that good stuff. So that overcomes the sort of procurement objection. But there's another big difficulty in actually being out in the field and trying to sell a usage-based or consumption product, which is you have to enable and equip your sales force with a much finer-grained, detailed, technical, engineering-centric type understanding of what each of your product does. To a buyer, that actually ends up being very difficult and injects quite a bit of friction in the process. So what do I mean by that? Let's imagine a company like OpenAI that serves tens of different models, or a company like Databricks that in their platform has a whole bunch of different products

that have slightly different ways that they are charged for and monetized. But the beauty and the simplification here is that if you boil this down to an artificial credit unit, your seller gets to have a conversation with the buyer around how much do you need and what discount am I giving you per credit? And that sort of flattens and simplifies this in a very simple way. So I know there's been a lot of objections or fear around, hey, if I go usage-based, it's going to be really hard for me to actually get buy-in from customers. But I think enterprise businesses are being really savvy in realizing that credits are a great way to counteract some of those forces. Are you seeing most of the credit-based model are net new businesses,

like net new categories of spend? Or are we seeing traditional businesses go after a credit-based model? Both. And the particular market landscape where an existing company goes after a credit-based model is when they start being a multi-product company. The beauty of AWS is as you grow your spend and you start looking at all these saving plans and pre-commitments and all of that, you don't have to upfront contractually specify, I'm going to use 10% on Kinesis, 20% on ECS, 30% on RDS, exactly that level of detail. It's a flexible pool that I can use to draw down any of my usage. So I think the savviest companies are realizing

in our contracts and our MSAs, let's actually structure this so that the customer can use their credits on every product I have today, as well as any new products I'm about to launch in the future, so that you can just try and use and grow. Only if you're maxing up your commit

and we're setting up some intelligent analytics around this, we'll get our sales team to try to upsize or renew the customer. So I want to jump in maybe on the infra side a little bit. You talk about developer focus or facing. I noticed on your product, you're talking about metering infrastructure. So I think when we're looking at billing companies, I used some billing products in the past. I think they never call themselves infrastructure products. I mean, they are definitely treated as one if you're using the solutions. But given that you're changing how we're able to measure things, I'm assuming there's also

a lot of infrastructure required that's different than your sort of like, let's call it V1, billing companies. Billing is sort of like V let's call it V1, building companies, building this sort of like V2 usage base. Was there anything that you had to build that actually is quite different that maybe even your customers didn't even realize, oh, wow, it's actually that complex? What are some of the infrastructure pieces

that was surprising or really difficult that you need to provide here? One of the most surprising and with the benefit of hindsight, like powerful aspects of the Orb approach was realizing that Orb is a billing system that's built for change and evolution, not for stasis.

When you think of a lot of these billing V1 products, you think, okay, what's the implementation like? How am I going to like, you know, take my requirements spec from product around what are the pricing laws I got to support and figure out how to stand them up and move on? Maybe that worked 10 years ago when you're setting up your seed-based pricing and you're evolving it once every three years when you're running a price change. But I think the realization here is these companies that we support now have to think of pricing changing as quickly as their product roadmap changes. So that actually throws the whole infrastructure lens entirely on its head.

Because if we think about system design from first principles, what you have to do is you have to work with an understanding of what is the requirement spec and what are the goals I'm trying to solve for. How are those likely to change? But ultimately, I'm going to design a robust system that flexes trade-offs in a way where I can achieve and maximize my goals. And some of the customers that we're talking to, we start working with them three months,

six months down the line, are launching entirely net new products with a completely different monetization model than they had ever thought through. So that actually has pushed some really important product goals and infrastructure guarantees on our product roadmap that we think kind of make the core of the Orb product value and differentiation. So the first one is, for listeners out there, you can kind of think of Orb as a marriage

between a billing product and an analytics product. The analytics piece being, what is the data infra where you can ingest a whole number of events representing usage across a bunch of different data sources? And the billing piece is how you can connect that to actually charge your customers. What we realized early on was it's really important to build our infrastructure around the ability to ingest events in their raw most format. So you can think of like two competing approaches to thinking about infrastructure for usage-based billing. Approach number one is this is like a massive data problem. Let me think of it as just like a streaming type solution where I'm going to materialize at ingestion time some aggregates and calculations

for the metric that you're going to charge for. Again, that's like the billing V1 type mindset where I need to pre-define up front what my pricing model is. But if that fundamentally is up for change, instead, what we want to enable and what we enable with our product is the ability to change that value metric definition over time. We actually built our infrastructure on top of Druid, a real-time OLAP database, where we're actually able to define, not at ingestion time, but at query time, what that calculation is.

And what that's enabled us is to have our customers realize, oh, I have to change my pricing. They're able to do that by just redefining the metric inside of Orb and not having to do a monster data backfill to achieve it. So again, I think that is just one indication that shows you that you emerge with a different product when you think that the core property that you have to solve for is this continual evolution and change.

I'm curious to think about, now that this is built, what are some of the exterior problems associated with pricing and packaging and how you evolve the business? That, okay, we have the info problem, but then you have the actual problem of, I have a business. It's not usage-based today. Maybe it's some weird ACB-based contracting

where I'm doing some type of weird per sale. What is the transition that you see companies have to go through to adopt a usage-based model? And how has it changed the go-to-market mechanism? I'd love to understand from your perspective what you've learned and how you think about how go-to-market with the usage-based is different than sort of your traditional seat model or other models that people pursue. I think that's what's so interesting and rich about this problem space. I started this company with an engineering perspective and an engineering bias.

The core objection that I had to overcome on myself was like, wait, how eng hard is this problem? Can't you just spin up an S3 batch job and move on with your lives? Where's the actual difficulty? Obviously, what that initial perspective underestimated was the depth of the problem. You start talking about the core metering infrastructure you need to support a consumption model. That's what's top of mind for an engineering builder thinking, should I build this internally or should I buy it? They're probably not thinking, what about that Salesforce integration that my CS team is going to need to know when people's credits are about to expire?

What about accounting? How do we do revenue recognition when all of a sudden I can't just straight line SaaS contracts and I have to actually recognize revenue based on the number of credits that are consumed? So what I love about this problem space and gets me riled up and excited about supporting our customers is that there's a significant amount of depth here.

And as you might imagine, we're lucky to partner with some of the best engineering organizations out there. And they obviously have wonderful data engineers and data infrastructure teams and all that. And a lot of their question is, wait, how hard is this? Or what should I do this?

And it's not a question of how hard it is. It's a question of opportunity cost. I think every second that you're spending on not billing is leverage for you where you get to build out your product. There's a real realization of depth in this problem space that is sometimes hard to underestimate or miss when you're approaching it purely from an engineering lens. But the second piece is that it's not just a billing automation, like how do you automate a pricing model type thing. It's actually a go-to-market culture shift. You can look at companies like Snowflake as really having pioneered

the way go-to-market teams are structured there. So they've done away with the standalone traditional customer success role and actually empowered their sellers as, hey, you're responsible for closing the customer up front, but also driving their consumption in the lifetime and expanding them to be more customers. So great, you're responsible for closing the customer up front, but also driving their consumption in the lifetime and expanding them to be more customers. So great, you've restructured your go-to-market teams. Now you have to think about how sales compensation should ideally reward that behavior.

I don't want to reward you to close a monster deal up front where the customer is just going to not use and churn. I want to reward you towards lifetime value of the customer. So now you're all of a sudden having to operationally track and think about how should my sales team be incentivized. What's exciting about building a business here is that these pricing trends are actually creating ways for modern go-to-market organizations to rethink the fundamentals of how they operate. And I'd like to think that a company like Orb can be a small piece towards helping affect some of these big changes. I think one of the most interesting things about all of this is the fact that it does

change the compensation mechanism of the sales team, how the customer success function works, if it works at all, if that collapses into the sales org itself, and how that finally changes what type of products those organizations who adopt usage-based will build. There's basically two sales models. You sell what's on the truck, or you sell a roadmap, the future of a roadmap. And Snowflake, from a sales perspective, is a great place to work because as an engineer, you don't spend so much time trying to build a roadmap someone else committed you to ahead of time to close a deal.

Because what Snowflake is focusing on is selling what's on the truck in a small use case and then growing you over time once you fulfill the bigger thing i think that fundamental difference with a usage-based model which best sits in things like infra let's be honest like the modality of infra products is really well aligned to use-based model because they're a building block but there are a lot of other things that also can have an infra-like modality and in many ways of other things that also can have an infra-like modality. And in many ways with AI, more things will have an infra-like modality because more things will be less about, oh, this is four full-time equivalents that we're moving from your organization. It's like, well, it is no full-time equivalents because you don't have that part of your organization. Or they're using it every time you use it.

You charge different because the value prop is different because the productivity increase is different and is measurable to, oh, you're going to have four or less employees. And now maybe you're still going to have 10,000 employees, you're going to have 10,000 customers interacting with an AI bot that has three agents that work with it. The modality is different, so this is right. I'm curious, when you speak to customers, how often do they think about how the change in usage base also changes the actual internal way that they work and thus the innovation engine of their business? At the end of the day, you don't have to sell specific features for specific customers to close a $5 billion AR deal. Instead, you can sell them, here's a million in credit, and here's what we plan on delivering over the next 16 to 24 months.

That's a completely different modality of sales, and thus the internal like rd mechanism can be different i'm curious like what your experience or observation have been in terms of how that changes the way that companies operate prioritize and effectively build and then thus compete i think we're probably still at a stage of the curve where what i'm seeing is that most people don't realize how much of a secular shift this is how much like second third fourth order consequences this type of thing has, and they're kind of going along with it. One thing that's really exciting,

and maybe this is a selfish perspective as an engineer allergic to very non-transparent sale motions is that ultimately, whenever you're aligned to be much more usage-based, you're pushed to put your product front and center into the decision of like, hey, is this valuable or not? Which means I think you have an incentive towards reducing unnecessary bullshit friction of people not wanting to tell me, how does the pricing work?

Or wait, actually, how long is it going to take me to implement it? You have a much higher bar to get to a moment of truth. Second, from an R&D perspective, you have is it going to take me to implement it? You have a much higher bar to get to a moment of truth. Second, from an R&D perspective, you have to prioritize time to value a lot more. Because if your whole business strategy is, let me get an on-ramp use case and let me get somebody in the door, sell them what's on the truck and start going from then on,

in the way you build a product, I think you are much more incentivized to prevent against this shelfware. You build a product to check think you are much more incentivized to prevent against this shelfware, you build a product to check off an enterprise sales requirement, and nobody uses the darn thing. So if anything, I think that's just pushing product teams to have to be a lot more proactive to how to meet the way a modern buyer wants to buy software. And honestly, I love that because I think that that just is aligning incentives where the whole industry as a whole, I think, is going to be propelled forward a lot faster.

So I think that's a perfect segue into our next section we call Spicy Futures. So let's just say in the next three to five years, what do you believe that most people don't believe yet or don't know yet? And just give us your hot takes here, sir. I think what, this is very related to what I've been saying. I think what most people are not realizing is that modern pricing trends are going to completely upend the way every team works from R&D to go to market. The big symptom that they're going to experience is, holy cow, this is changing a lot faster than I could predict.

If you take a clear trend that's proliferating massively like AI, and you're seeing just the timelines of innovation that we're seeing in that, I think that is just a great leading example about how every modern R&D team, go-to-market team, business leader is just going to have to be able to react and think about how to restructure their companies a lot faster. Now, the way that they're going to, I think, experience this is, again, bringing the org perspective here, is that they're just going to see their pricing evolve a lot faster.

And they're going to realize, I actually don't need a traditional billing infrastructure system. What I need to buy or solve for is how can I be an agent for growth and how can I ensure that companies grow to the rate that my like leadership team is asking for? This goes back to what I was saying that a lot of engineers underestimate how hard billing is. And when they learn a little bit, they're like, oh my gosh, I got to think about time zones and I got to think about prorations and a lot of the, they're still thinking about how difficult is it to build the features to support my billing model today. I think what people just underestimate is that you got to reframe that thing entirely. And you actually

have to think about how can I build a system that is going to enable my product org and my company to be able to very nimbly change and evolve? And obviously, we think that the answer to that is work with Orb, because we happen to have this vantage point where we're not solving for the requirements of one company. We get to be part of the scaling journey across all of our customers, get to see experiences from cloud infrared to fintech to data to AI to a whole bunch of spaces. And we think we've built a really good product in the space to actually propel folks forward in that spirit of change.

Five to 10 years from now, what do you think infrastructure selling looks like? What do you think it looks like to buy infrared? What do you think it looks like to build and sell infrared? And how is that different from today? We're certainly not in the beginnings of the beginnings of cloud. We're definitely in the end of the beginning of the cloud software shift. But this is like multi, multi, multi decades transformation of the way that we build and run and buy and operate software. So I'm curious to think, 10 years from now, what's it look like? And how much does usage-based billing play a part in that?

I think playing it forward predictions here are first, product-led growth or PLG stops being like a delivery mechanism and just becomes like a table stakes way to evaluate a product. Even though a lot of companies have made great strides in reducing the friction that it takes to understand, wait, what does your product actually do and how does it help me? There's still some antiquated sales process associated with it. So I'm excited to think about what does a fully headless sales process look like down the line, where maybe you could imagine that if I start by having to solve a customer business problem made up of infrastructure Lego blocks. Can I sort of stitch together an agent-like evaluation process where I get to sort of swap interchangeably an evaluation mechanism and protocol from different services and providers? That's kind of an out there idea, but I think that's really where we're going to be pushed on as business leaders to think about how can I make it much faster and efficient for

a savvy buyer to not waste their time and actually think about what is the right way to procure. So I think we're going to see more and more of that. And second, I think the role that usage-based billing will play in this is just doing away with non-transparent business practices that just don't serve the ecosystem as a whole. So in this conversation, we're talking about that shift from trying to commit someone to the largest contract up front as possible versus get somebody in the door, sell them

what's off the truck and grow them over time. That's not just naive or aspirational capital good business practices. It's actually been proven to be immensely successful for businesses like Snowflake that have off-the-charts net dollar retention rates. And they're building incredibly strong businesses with really good fundamentals that are compounding over time. I think more and more customers and companies are going to realize that the way to be successful is to actually meet my buyer from what they're asking for and try to drive transparency and try to build trust in what they're doing. So I'm excited about what this is

going to mean for the ecosystem as a consumer. So I'm curious too, because the pace of change has been increasing and how enterprises have been thinking, what kind of products should I rely on to build and sell either from the R&D to the golden market? I think that's still up to debate. There's a lot of learning that's happening right now. I was curious when you're talking about analytical companies and billing companies, right? You're basically combining both. You're getting a lot of fidelity of the similar kind of data that analytical companies are getting in the first place. Do you think in the future you will be subsuming analytical products and just like, here's a Uber product, everything just takes one? Because there's obvious advantages for that, right? I don't

want to have like three places and dumping every data from and you're doing for billing, I'm doing for security, you're doing for analytics. Like you should have like a lot of usage, but same amount of data. Do you think that's where we're going? Or do you think, hey, there's going to be consolidation, you know, because that's what outcomes are more closely aligned now. I need to see the analytics to help me do pricing and pricing is going to change how products work. Do you have a prediction what this might be? Because I'm very curious. It feels like the products of the future will change as well. I think they will. And I

think there's going to be a big push towards consolidation. And it's actually, the bar is going to be raised for vendors like Ord towards really justifying and proving their value. And I think it's only natural to want, as a buyer, a bit more of a consolidated one-stop shop that solves my problem. There is some sort of total cost of ownership economic argument for I can save money. But I think the fundamental here is I need to have my customer problem solved. And my customer problem is not decomposable along the lines of modular products out there. We actually see this quite a bit at Orb.

So over the three years that we've been around, we've built the platform to support the metering, sort of ingestion capabilities, the billing capabilities, as well as invoicing and delivering invoices to end customers and providing reporting for internal use cases like analytics and revenue recognition. If I were to run a whole of my market out there, I will be hard-pressed to find a customer that can break this problem down along the product modules I just described.

They're thinking of billing as this customer problem of, I got to get money in the door. So why are there these vendors out there that are trying to be like these super sliver narrow type solutions? So it's a very rational and understandable viewpoint that's not just driven by, I want to save money. It's actually driven by, I just want a full solution to my problem. So I got to stop thinking about this. So I think macro environments are really conducive time and time again towards more consolidation plays rather than the modular software plays. So I think there's a lot of that going on. in the coming future with AI innovations around how engineering teams build product, that's only going to raise the bar for more differentiation in product solutions. As startup founders, we're going to have to push the boundaries even harder on product innovation and differentiation, but I think it's net good for competition. Awesome. So where can people find about you and Orbs? Give us some of the social things and actually anything you want to talk about, some latest launches or anything will be fun too.

Yeah, absolutely. Folks can check us out at withorb.com. That is W-I-T-H orb.com to come and learn about our product, as well as some of the customer stories for who we've been working with. In the spirit of this conversation and the spirit of 2024, what I'm most excited about is some of the near-term features we're building in our roadmap around this idea of business model evolution or orchestration. So with the years of experience that we've had with our customers, helping them change their pricing, run massive price changes, we're really excited that early in the year we're going to be launching capabilities from within Orb to let you automate and orchestrate changes to your business model. So for folks that have started to think about, how do I actually evolve my pricing?

How do I go from seat-based today to usage-based in the future? I think we have some really powerful product capabilities coming soon. So if there are any listeners out there that would love to learn more around these features specifically, we're kind of kicking off a little bit of an early access program. So folks can reach me at alvaro at withorb.com, A-L-V-A-R-O, to learn more about that. Awesome. Super great to have you on, sir. And I hope you enjoyed the podcast so far.

Thanks for the great conversation. It was great. Thank you.