Building Billing Infrastructure for AI Companies | Alvaro Morales, CEO of Orb

Alvaro Morales is the cofounder and CEO of Orb, a usage-based billing product for modern software companies. They've raised $44M to date from amazing investors such as Mayfield, Menlo Ventures, and Greylock. 

Alvaro's favorite book: Conversation in the Cathedral (Author: Mario Vargas Llosa)

(00:01) Introduction 
(00:35) What is Usage-Based Billing?
(02:27) Challenges in Metering Usage
(04:14) Examples of Consumption-Based Products
(05:49) Tools for Usage Metering and Billing
(09:08) Founding Story and Validation of Orb
(12:11) Building the MVP for a Billing System
(14:48) Acquiring the First 10 Customers
(18:33) Scaling Sales & Marketing After Initial Traction
(21:09) Building the Team & Ideal Candidate Profile
(23:26) Technology Stack Behind Orb
(25:55) Real-Time Analytics vs Streaming for Billing
(27:18) Other Key Components of Orb's Solution
(28:38) Why Incumbents Haven’t Solved This Problem
(31:09) How Orb Uses AI Internally
(32:53) Most Exciting AI Advancements for the Future
(34:30) Rapid Fire Round

--------
Where to find Alvaro Morales: 

LinkedIn: https://www.linkedin.com/in/alvaro-morales/

--------
Where to find Prateek Joshi: 

Newsletter: https://prateekjoshi.substack.com 
Website: https://prateekj.com 
LinkedIn: https://www.linkedin.com/in/prateek-joshi-infinite 
X: https://x.com/prateekvjoshi 

Transcript

Prateek Joshi (00:01.404)
Alvaro, thank you so much for joining me today.

Alvaro (00:04.504)
Thanks for having me. I'm excited for the conversation.

Prateek Joshi (00:07.196)
Let's start with the basics. with the AI taking over everything, usage-based pricing is becoming more more important. There was a time in the past where I buy software, I pay a monthly fee for a seat, and everything was good and dandy. But now, everything is changing. So let's start with that. What is usage-based consumption? And also, what is usage-based billing? What does it entail?

Alvaro (00:35.958)
Absolutely. So the core of this is that now pricing is aligning a lot more to the value that you're getting out of the software or non-software product that you are utilizing. So rather than paying for that fixed seat fee or that monthly gym subscription, even though I don't go into the gym, pricing is a lot more about the actual value that you are getting out of a product.

And a great way to get to measure what value you're getting out of a product is through your actual usage or consumption of the product or service. So for example, in the cloud infrastructure world, when you are paying for compute or workloads, it's great to pay for what is the actual workload that I'm running through a system. At its core, I think what we are seeing is a general big movement of the software industry towards aligning pricing a lot more to product value.

and a big rise in acceleration of usage-based pricing across the industry. Specifically, I think this has been greatly accelerated by just the explosive innovation around Gen.AI, where a lot of the value that you get out of many Gen.AI products has nothing to do from whether you get like a user password login on a web application. It's a lot more about what outcomes or what automations those are driving. So it's kind of a perfect fit and really good scenario.

for more of these flexible usage hybrid or outcome based pricing models. And they're taking the industry by storm. Now, the big challenge here is that this pricing is inherently valuable. So how you calculate what your customers owe you, how you do that billing is inherently a little bit more complex. Usage based billing really focuses on a special purpose custom built technology solution to power that kind of pricing flexibility.

Prateek Joshi (02:27.71)
Now, in the past, measuring the number of people using your product, it's pretty simple. You count the number of people, you send the bill. Hey, people using the product, 30 bucks a month, that's your bill. But in this world, what makes it difficult to meter the usage? What are all the things you're seeing out there? And what makes it difficult to kind of measure the consumption?

Alvaro (02:54.978)
you can kind of think of this as having data infrastructure complexity, but also business complexity. So what I mean by this is, let's say you are running a large scale, high performance, low latency infrastructure service. And it is very important that you have strong analytics tracking and metering to make sure that you have a detailed understanding of how customers are actually consuming.

Now, it's one thing to think about this as a data infrastructure problem, but I actually think that a lot of teams are amazing at data engineering. So perhaps the metering and counting of this is not that hard. Where things actually get a little bit tricky is when you intersect some of this complexity with real world business complexity of customers paying certain plans or having custom negotiated contracts.

And then all of a sudden, what you're doing is you're essentially exploding out and intersecting a lot of data volume that is very finely being metered across the service, a lot of complex pricing structures that are getting negotiated on a customer by customer basis. And I think that this match and this intersection inherently creates a lot more complexity on a billing process.

Prateek Joshi (04:14.086)
What are some of the examples of consumption-based products out there? So for example, a simple example is if I'm using AI for customer support or ticket resolution, the number of tickets you resolve for me is one way to measure success, and I'll pay you for that. You resolve 10 tickets, I'll pay you one amount. You resolve 1,000 tickets, I'll pay you more. Now, what are some of the other examples of consumption-based products out there?

Alvaro (04:42.574)
Many, many really great examples showing up in AI products. So for example, many products that handle application development or UI generation, such as Versailles v0, are metered on a token basis. So basically an abstraction over the computational inference resources that it takes for those models to produce new applications. A token is a great way to measure and charge for that.

When you think of more agentics type solutions, such as Replet Agent, the amount of work or compute that those agents are going off and doing for you also needs to be measured. And tokens are also a great way to do that. You think of data infrastructure services around real-time data streaming and or data warehousing.

They're often measuring compute, network, and storage, these sort of low-level fundamental resources of computing that ultimately they deliver a value-added service around and think about their pricing strategy based on those core value metrics.

Prateek Joshi (05:49.106)
Great. That's helpful. And looking at all the tools, the current landscape of tools that are available to do this, meaning let's say I'm shipping AI software and I want to meter it so that I can send the right bill to the customers. What tools do we have at our disposal to do that today?

Alvaro (06:10.062)
By and large, a lot of custom in-house bespoke software that teams end up building as a shortcut or path towards getting the products out to market. And then over time becomes maybe a real maintenance burden and or blocker towards fast shipping velocity. So let's maybe take a look at a little bit of the building landscape that exists out there for companies. So these founders, these vendors that are thinking about, I have an amazing innovative product that I want to get out to market.

And obviously how I monetize that product and how I think about its pricing and packaging, it's going to be really core to its success. There's sort of an ecosystem of traditional billing systems, incumbent solutions that have been around for 10 plus years that are really optimized and oriented around this idea of a subscription seat billing model. So in the advent of cloud and that first wave of software, alongside that computing shift, there came a business model shift.

that led its way and drove its way towards that subscription seat business model. The thing about this though is that maybe the core data model unit, the core abstraction that those systems are built around is this idea of a subscription that has kind of a fixed seat cost per month that recurs on a regular cadence. And maybe you can think of a lot of those systems as being optimized for a once a month back office financial process where there is a billing cycle that needs to be completed

on an ongoing cadence. Now here comes along usage-based pricing with a lot more dynamism, a lot more variability, a lot more of a need to create transparent user experiences where your customers, they don't have to wait till the end of the month to know how much they're going to pay. They actually have to know about this as they're interacting with a model, as they're interacting with an agent to kind of develop and get an understanding of the value and costs.

This is a different kind of solution. It's one where it doesn't just serve the purpose of a back office financial process. It actually is much closer to the customer and the customer's experience with your product. And it is a kind of service that needs to be massively scalable to support explosive growth. It needs to be real time and near real time, very responsive to user input and user consumption patterns. And it needs to have the availability

Alvaro (08:35.064)
to often be right alongside the rest of your application. Maybe that's the place that solutions like Orb in the usage-based billing space are really filling for the market. And I kind of like to think about this using the analogy of the marriage between an analytics product and a billing product. So both giving an immense amount of insight in what that customer consumption and billing and invoicing calculation is, but obviously also with the potential to give a business huge insights about the success

of their product market fit and the success of their business growth.

Prateek Joshi (09:08.082)
That's a good segue into my next question about Orb. To solve this problem, obviously you launched Orb. So let's go back to just before launching. How did you validate the need to build this before launching the first version of the product?

Alvaro (09:27.978)
Absolutely. So my background is in software engineering. joined Asana and was with them through their major growth phase from like the early monetization of their product to them being a public company. And through that experience, got to really see how the business had an amazing opportunity towards evolving and improving its pricing and packaging. A discipline by the way that

coming into that job and knowing nothing about pricing or billing, I thought was going to be all math and statistics and models. But I fell in love with the discipline upon realizing that it's just an incredibly strategic exercise that's about the customer and about the product and about understanding the value that those customers are getting out of your product. So I thought there was like a wealth of opportunity and really the possibility of doing right for the business and customers.

But unfortunately, over and over again, I had the experience of witnessing how the systems that we had in place slowed that down, where some great ideas that folks on the business side would come up with would be met with uncomfortable engineering voices in the room, myself included, having to say, I'm sorry, but that's going to take us six months. That's going to take us 12 months. Yes, it sounds very simple, but turns out that it is a fundamental assumption difference that's going to require a huge amount of effort.

That's very dissatisfying. And, know, it really inspired that my girlfriend and I had to start Orb because this idea that this is just backwards, right? These tools, this infrastructure is supposed to enable the possibilities that you're dreaming up about your business, not constrained and, you know, paint you into a corner. So I think we start Orb with this founding vision of bringing the essence of a developer platform.

that is the flexibility, experimentation, iteration of developer platforms into the space of billing and revenue infrastructure. And some of that validation had come from that firsthand experience, knowing some of the challenges around evolving pricing and packaging, but seeing many of these infrastructure AI automation companies really struggle with this problem at a much larger dimension and earlier in their company building journey.

Alvaro (11:52.172)
So maybe the challenges of a pre IPO or public company that we lived were happening right at the commercialization of the product. So I think that that led to a lot of the inspiration here.

Prateek Joshi (12:03.038)
What did the MVP look like? How did you decide what features should go into it?

Alvaro (12:11.202)
It's a great question, especially because when you think about an MVP, the idea of an MVP doesn't jive super well with a billing infrastructure system because we have to remember that in the end of the day, a billing system has to bill and billing must be correct. So it was really intentional and a hard question for us to think about, like, what are ways that we can

sort of slice and dice this capability where ultimately there needs to be an end-to-end life cycle where everything from capturing and ingesting data about product usage, intersecting that with a pricing configuration, generating an invoice and integrating with the rest of the financial stack, that's kind of a cohesive atomic flow. On the other hand, we also, as both engineering founders, kind of started the company with a strong conviction that

We didn't really want to go down to the basement and be writing a bunch of code for a product that nobody need. So we kind of needed to find a way to meet both of these goals of having an atomic cohesive MVP product, but one that we could validate with customers in an ongoing way. So the way we approached it was, first and foremost, thinking about the structure and scaffold of this process and workflow that I described for you.

being very, very thoughtful about how we prioritize which of these boxes do we fill in first, and obviously the ones that were absolutely necessary for a complete workflow, and then found that it was tractable and workable to take more shortcuts on the integration or sort of full additional manual workflow side. So it's almost like, can we get the core of the engine in place and then over time build on top of it?

to get us a fast path to market. And yes, that actually meant that Orb's first billing cycle had a manual review step where myself was auditing and making sure that every single invoice was correct to our spec. And there might've been a little bit of like manually generating the invoice PDF using Google Docs to get that up and running and ultimately sort of filling this together, but sort of fun little shortcuts that one looks back on.

Alvaro (14:37.144)
but ultimately contributing towards this maxim that we tell our team and talk about internally, which is billing must be correct.

Prateek Joshi (14:48.03)
Now, that's a great nugget. Now, the acquiring the first 10 customers, it's a very different journey for all the different companies. There's so many things you have to try, many things, almost nothing works in that phase. And something like a little bit of something starts working. So the journey from zero to 10 customers, what are all the things you had to do? And what are the learnings now looking back on that part of the journey?

Alvaro (15:18.818)
Maybe as I look back and think about that journey, one thing that comes across is it was a grind and it was bit by bit, one by one. You get the first customer, then you get the second and it sort of slow, steady, a ton of hard work going into it. It actually created quite a bit of a challenge for us. I'm a first time founder and I shared my background prior to Orb as an engineering.

I made a promise to myself and my co-founder that we would validate the market and even secure some customers before we would write a single line of code. Almost like to prove to ourselves that we wouldn't fall prey to a prototypical first-time founder mistake. The thing that was trickier and more nuanced for us to internalize was how to interpret a no from a

prospective customer that we were trying to sell into. Because what we learned is there's two different kinds of no's. One kind of no is no, this problem statement does not resonate with me in my experience. Sort of this solution idea doesn't solve an actual problem that I'm facing in my day to day. No. Maybe from that shape of no, you can really take away maybe some invalidation of your hypotheses or some challenges.

around the market opportunity that you're going after. There's another kind of no. The other kind of no is, look, I really resonate with this problem statement, I live a day to day, and you are two founders with a slide deck trying to get your hands on our company's billing and revenue infrastructure. So sort of the dimension of what kind of trust leap does an early customer need to take?

to not only validate and resonate with a problem statement that you're going after, but also be willing to go on a journey where they're going to be a little bit of a guinea pig and go along of an early ride with you. So obviously, we're grinding, we're doing all sorts of cold outbound, warm introductions, everything like there's no magic secret. was sort of a ton of activities and steps and getting a lot of notes, which is a little bit of a gut punch, right?

Alvaro (17:44.28)
But I think it sort of added up to us understanding and learning how to tease apart that market validation and identifying that rather than brute force selling, we were in some sort of matching process to identify a counterparty that would have two properties. One, be living the problem that we're facing, but two, have this problem be a hair on fire enough and

at a particular stage in size such that they would be willing to be a very early adopter of what is undeniably very mission critical software. So it's almost like that trust leap to me as a founder was a really important dimension to internalize in that kind of early search for product market.

Prateek Joshi (18:33.406)
That's an amazing framework, learning to differentiate the two types of no's and also figuring out what are the things you can use and what are the things just, hey, this is a wrong mismatch between customers. They've never encountered this and there's no one. That's really great. Okay, so now, you got these handful of customers, you knew something is kind of starting to work. Now, after that, you have to grow. You have to get more customers.

After that, what sales and marketing experiments did you run to try to kind of speed up customer acquisition? And also, what worked, what didn't? And if you had to kind of take out the top three learnings from that, after the initial handful of customers to now, what would that be?

Alvaro (19:25.602)
Well, even in sort of the framework that I just shared with you, maybe that reframed our early customer acquisition from a purely growth exercise to a little bit more of a trust building exercise where the goal was get customer number one, make him incredibly successful, build up that trust and figure out how we can go from that one customer to others. So as part of that, maybe very successful sales and marketing experiments,

had to do with realizing that many companies have strong ecosystem network effects. So even you look at Orbs customer base right now, literally, I think almost every single vector database out in the market is an Orb customer. You look at major cloud infrastructure developer platform providers, they're Orb customers. So what we found a really good way to do was

almost use the trust and success we had carved out and built with one customer and think about in a sub-vertical or subcategory here, what are some network effects that exist and could we use those to go from customer to customer?

Prateek Joshi (20:45.308)
And if you look back on going, customer acquisition is one, but going up to company building as a whole, and obviously to build a company, need product, team, customers, so many other things. So what are the biggest challenges you had to overcome to build the company as a whole?

Alvaro (21:09.876)
I would say building a team as being a really important step and critical step towards the success that we're seeing at Orb. So in that, maybe outside in, Building doesn't seem like the most interesting or exciting category. How do you motivate? How do you really connect with a certain...

kind of person that would resonate with that space. So in particular, if you think about what anybody's job at Orb entails, you get to have a front row seat in the growth stories of some of the most amazing and foundational and fast growing companies that exist in the software ecosystem. right now, mean, you take a look at customers we have like Vercell, Perplexity, or Pinecone.

They're each in sort of this incredible innovation journey where they're launching sort of category defining products. And there's a particular person that's gonna be really motivated about inserting themselves at that point of leverage where the impact that you can have at Orb has the opportunity towards having impact on the growth stories of a lot of other businesses. Defining that, call it ideal candidate profile, that ICP, which is as important as an ideal customer profile,

I think represents an important early challenge that you have to kind of realize that ultimately your goal as a founder maybe is just be clear about what your company is and who you're looking for. Be clear about what you stand for in a polarizing, ideally polarizing and not off putting, but certainly sort of self-selection way. And then again, go out to find that amazing team that can build the success that you really are setting out to build.

Prateek Joshi (23:08.068)
amazing. Okay, so going to the technology part of the company, can you walk us through the tech stack behind Orb? Like what have you used to build this and what components are more complex than others?

Alvaro (23:26.678)
I think the insight that we Orb around is that the fundamental problem that Orb is here to solve is one of change and evolution. So what our customers hire Orb for is not just to help automate the business process that they have today, so that ideally their engineering teams can go spend time building products instead of building billing. But it's also the fact that some of the customers that partner with Orb

in six months, in a year, end up coming up with new product lines or commercial strategies that they didn't even conceptualize or imagine. And it is Orb's job to have the flexibility and adaptability to always be a step ahead of them and support their ability to ship their pricing as fast as they ship their products. So let's intersect that insight.

into a very, very important data architecture decision that we made in the beginning. When many people think about usage-based billing or consumption-based billing, the thing you immediately think about is scale, big data volume. I'm metering very fine-grained quantities and I want to make sure I have the infrastructure reliability to be able to aggregate and calculate inversing off of.

Upon starting Orb, we of course realized that if we don't deliver scalability, low latency and high throughput, we're not a business. That's like a table stakes requirement and without that, Orb wouldn't be viable as a business. But furthermore, when we think about that sort of idea of change and evolution, we had to have a data architecture pattern that enabled Orb's ability to be as adaptable.

Again, when you think about consumption billing as strictly just a data problem, maybe the paradigm or idea of real time streaming where you have a massive event stream that you're running up against a pre-configured pricing structure and you're using that to calculate invoicing, seems like a natural tool to reach out for. And in fact, a lot of our competitors or existing solutions maybe have naturally gravitated towards that. Orbs technology stack difference and data architecture difference is that we adopted

Alvaro (25:55.138)
more of a real-time analytics model, where we ingest product usage and metering events and store them in its raw form in our back-end data store. It's a technology architecture we called the rev graph or revenue graph that really supports Orbs ability to handle workflows like billing and invoicing very performantly and accurately, but also insights like what are

customer consumption trends, or can you simulate alternate pricing structures on top of that existing historical data? So our insight here was, if you're trying to power future evolution and analytics, you can't just pre-configure and sort of preset yourself into an upfront configuration. You actually have to have the viability and flexibility to try out alternate and dynamic strategies on top of that. So when you think about that,

streaming data model versus a real-time analytics model where a lot of OLAP data stores and the like are built around or chose that as kind of the fundamental choice we were making around this technology. And I think it's enabled us to deliver unparalleled flexibility on what's out there in the market.

Prateek Joshi (27:08.382)
Apart from data infrastructure, what other components did you have to build to provide a full working solution to your customers?

Alvaro (27:18.882)
Yeah, I mean, if you think about Orbit, we're a single product, but under the hood maybe we're two products. One is that really high scalability data ingestion API and a very robust web application that supports a bunch of finance workflows, such as ensuring that customer consumption is accurate, that invoices are being sent out. So we developed a...

We've developed our web app on top of the Next.js framework, the Vercell deployment ecosystem. And I think that choice has given us the ability to be like a lot of flexibility and a lot of rapid iteration to deliver on some of those workflow improvements.

Prateek Joshi (28:06.398)
And if you look at the big fintech companies, for example, Stripe, this seems like right in the wheelhouse in the sense that if I'm thinking of building, one of the many big finance companies, can you maybe explain why one of those big companies, haven't they done, clearly it's a big need and I'm already their customer.

Is there a reason they haven't done this or they can do it but they're choosing not to? Can you talk about that?

Alvaro (28:38.606)
Yes, and I think it's a really good observation that companies like Stripe, I think very much have also identified the need and have taken many steps to try to serve this market need. I'm somebody that really likes to think about incentives and structural shapes of markets to understand, can they give way to amazing startups that can really disrupt incumbents there? And maybe...

a lot of those companies have an incentive structure where perhaps their core business is more on the payment side rather than the kind B2B workflow oriented billing side. And that maybe naturally is going to put some upper bound on the amount of innovation investment that those areas can have. Second, is there enough of a architectural difference to create way for a well executing upstart to find and solve a very specific and acute and growing market need?

well enough to leapfrog past those incumbent solutions. I'm somebody that believes that, especially in this day and age, true technology modes are probably really vanishingly rare. That meaning in the fullness of time with a significant amount of engineering investment, probably there are no true technology modes. The question though is, is there enough of a window for a well-executing startup to show up to a market

with a differentiated point of view, a different angle of approach, solving a customer problem 10x better, execute on that increasingly well, such that no matter which named incumbents with thousands of engineers exist on the playing field, that can create enough of a mindset shift to really lead way towards innovative, enduring new businesses. So I think it's really kind of exciting and important as a founder to bring that

intellectual honesty lens into the shape of a mark.

Prateek Joshi (30:37.182)
love that answer actually. It's a nice way of thinking about why incumbents can't or won't do something. It always starts with incentives, right? So just look at where the money's flowing and you'll know very famously as Charlie Munger, like show me the incentives and then show you the outcome. That's what he said. So fantastic. Okay, so inside orb, where do you use AI for yourselves, for your own work?

Alvaro (31:09.03)
across many areas of the company. And in particular, I think I spend a lot of my tinkering time using AI on our go-to-market experimentation. So across the company, we use AI to power some product experiences, to increasingly help facilitate how easy it is to get set up and running with Orb.

Our engineering team uses a number of solutions towards really augmenting their productivity and making sure that maybe what before took a team can be greatly accelerated with both the development, but also testing and safeguard technologies that exist. I've spent a ton of time building with a lot of interesting tools in the go-to-market engineering space. So when you think about things like

account qualification, total addressable market mapping, the ability to think about surfacing insights and signals around buying intent. I just think that we're in an entirely new world where, I don't know, my guess is that every dollar in customer acquisition that you can spend can probably be a whole lot more efficient if you're spending your time tinkering with some amazing tools like Clay or Co-op.

Prateek Joshi (32:33.15)
Amazing. All I have one final question before we go to the rapid fire round. Now AI is moving so fast and it's being applied to every sector. So what AI advancements are most exciting to you as you look forward to building your company?

Alvaro (32:53.762)
I think there is one, the opportunity for a lot more creation capability. So what I like to say at Orb is that prototyping is often the first step towards solving an amazing customer problem. And when you think about the kind of nascent set for builders to really prototype and conceptualize their ideas out there,

I just feel like it pushes the bounds of what's possible and is a little bit of a necessity with how competitive any market and any landscape is getting. But when I think about just what can be really truly turbocharged is you are massively lowering the barrier on how possible and easy it is to prototype and conceptualize. I don't think we're quite near at the like software engineering is dead and you

You don't need to hire amazing software engineers. I think there's quite a bit of noise on that regard. But the ability to go from idea to something visceral, tangible that you can experiment with, I think is huge. And then on the other hand, I think the efficiency that builder teams on the sales and marketing side, areas that I am obviously spending a lot of time as a founder these days.

Probably what required years before can now be done in a weekend using some of the tools and technologies that I mentioned.

Prateek Joshi (34:30.928)
Amazing. All right with that we are at the rapid fire round I'll ask a series of questions and would love to hear your answers in 15 seconds or less. You ready? All right question number one. What's your favorite book?

Alvaro (34:41.144)
Let's do it.

Alvaro (34:47.768)
Tough one, but I recently reread Conversation in the Cathedral by Peruvian author, Mariualga Sosa. And that is just, I love that.

Prateek Joshi (34:56.88)
Which historical figure do you admire the most and why?

Alvaro (35:02.168)
Galileo Galilei, because I think it says a lot to stand up for one's beliefs.

Prateek Joshi (35:07.612)
What has been an important but overlooked AI trend in the last 12 months?

Alvaro (35:13.048)
I think I'm going to go back to sort of the impact of AI on go-to-market and go-to-market engineering. I think the thing that's well known is all these applications and automations like AI SDRs, but what's not getting enough attention is that the efficiency of all the things that you were doing, but focused on a better account list can probably just have really sizable impacts towards the kind of ROI you get out of those activities. I think that that piece is not getting talked about enough.

Prateek Joshi (35:40.646)
What's the one thing about usage-based billing that most people don't get?

Alvaro (35:48.238)
Corrections and exceptions are the stable system property to solve for, which means that flexibility and adaptability is actually the core requirement.

Prateek Joshi (35:58.246)
What separates great AI products from the merely good ones?

Alvaro (36:03.756)
discoverability of capabilities and user experience.

Prateek Joshi (36:07.464)
Love that. What have you changed your mind on recently?

Alvaro (36:14.424)
The importance of switching up your cadence and rituals for product planning and execution, thought that just predictability was the thing to solve for, but I think it is really powerful to be in different modes of innovation and maintenance, and often even switching things up can really help push a team forward.

Prateek Joshi (36:36.818)
What's your wildest AI prediction for the next 12 months?

Alvaro (36:42.296)
prediction slash hope that there's a new communication paradigm that is disruptive enough to break down the network effects of Slack Connect and shared Slack channels so that we are in a new different world.

Prateek Joshi (36:54.758)
Right. All right. Final question. What's your number one advice to founders who are starting out today?

Alvaro (37:02.912)
Maybe that there's not really a new playbook or new way to build an enduring business, even though it feels like there's a lot of new things right now. Maybe just focus on talking to customers.

Prateek Joshi (37:16.35)
Amazing. This has been a great discussion. Love all the nuggets about just building and shipping. There are so many things you had to get right and so many things you had to try and most of them won't work. So thank you so much for coming onto the show and sharing your insights.

Alvaro (37:30.926)
Of course, thanks for having me.