Sam Dhar has spent 14 years building infrastructure at Cisco, Amazon Alexa, and Adobe, and now works as Senior Staff Engineer and AI infrastructure leader at Galileo, the enterprise AI evaluation platform. In this episode of the Smooth Scaling Podcast, Sam walks host Jose Quaresma through Cloud Prem: deploying your full product stack inside the customer's own cloud environment instead of running it as SaaS. They get into why the model is resurging, and it mostly comes down to data. Enterprises want ownership and control, plus a heavy compliance load (SOC 2, HIPAA, fully air-gapped government workloads), and they do not want a vendor sitting in the read path of their most sensitive data. Sam is candid about the hard parts. Cloud Prem can be a losing game on margins, deployment is the slowest thing in the pipeline, and every customer environment is different enough to reset the work. The conversation closes on AI: why it makes Cloud Prem urgent, the brutal GPU shortage, and why self-hosting an Opus-class model is still out of reach for most companies. A direct, practitioner-level look at where enterprise AI infrastructure is actually heading.
Satyam βSamβ Dhar is a senior Staff Engineer and AI infrastructure leader at Galileo, where he designs systems that support real-time LLM workflows at enterprise scale. Prior to Galileo, he spent over six years at Adobe, contributing to AI-powered product development, evaluation platforms, and large-scale data systems. Earlier in his career at Amazon, he worked on high-throughput distributed services supporting Alexaβs device orchestration. Based in San Francisco, Samβs insights and commentary have been featured in Newsweek, CNET, InfoQ, The New Stack, The Deep View, and others. He is also a Senior Member of the Institute of Electrical and Electronics Engineers.
Episode transcript (auto-generated):
Jose:
Hello and welcome to the Smooth Scaling Podcast, where we speak with industry experts to uncover how to design, build, and run scalable and resilient systems. I'm your host, Jose Quaresma, and today we had the pleasure of chatting to Sam Dhar, Staff Software Engineer at Galileo. We had a great conversation with Sam about the rise of Cloud Prem and how data ownership and control became the key driver to push enterprises to deploy Cloud Prem solutions. We also dive into the new challenges that AI and LLM workloads bring to infrastructure choices. If you like this podcast, subscribe if you haven't done so yet and leave a review. It really helps the podcast. Enjoy. Sam, welcome. Welcome to the podcast.
Sam:
Thanks, Jose. Thanks for having me.
Jose:
Very happy to have you here and looking forward to our chat. And in our chat today, we'll talk mostly about Cloud Prem. And I wanted to start by asking you whether you can share a little bit about what led you to focusing on Cloud Prem architectures.
Sam:
Cloud Prem is this technology where you deploy a cluster, a stack of your product, into the customer's environment, their cloud environment. And this has been around as a technology ever since, I believe, ever since the existence of on-prem. But more recently, it has seen a resurgence, especially in the recent age of AI. So a little bit of my background: I've been in the industry some 14 years now, an engineer through and through. I worked at large companies throughout my career until very recently, ever since the AI revolution started. I was at Cisco doing hardware stuff, and then I got into Amazon Alexa, and then most recently at Adobe for about seven years at different orgs. And each of these companies had one thing in common. If they had the chance, had the opportunity to have something running locally within their prod or their internal network, they would prefer to go for it. And for good reasons. And that's where Cloud Prem comes into the picture. On-prem is its very close relative, or actually its very close ancestor. And how I got involved with Cloud Prem for the first time was as a staff engineer at Adobe. I was tasked with identifying the best way for our systems to be able to scale compute, and we didn't want to load everything onto our existing compute platform that we had internally. There were also some scaling issues, or some very specific workload-specific requirements that we needed to support. For that, we needed a system that would be able to run compute and orchestrate it and completely run independently, but within our network, within our environment, and completely cut off from the outside external access. This was a property of a lot of our internal tools, where we deploy it internally with absolutely no access to the external users. And in that phase, I had a lot of research done into this specific way, specifically how this would be deployed into the Adobe Kubernetes environment, and how each of the vendors that we were working with would be able to scale well in the Adobe environment. That's how I got started, and eventually I migrated, or switched over, to Galileo, which is now going through an acquisition, as we speak, with Cisco. So kind of a homecoming, because I worked at Cisco a while ago. But going full circle. Galileo is a fully enterprise-focused Cloud Prem solution for AI evaluations, to run at scale but internally inside the enterprise cluster. So yeah, that kind of built that expertise, and that's how I've been involved with Cloud Prem.
Jose:
Yeah, and thanks for sharing, and thanks also for helping us kind of get an initial definition of Cloud Prem. It does look like Cloud Prem is, I don't know if it's fair to say, gaining some more traction now. Can you share with us what's driving that current shift to Cloud Prem? And maybe just, is it correct that it's gaining more traction now?
Sam:
Yes, absolutely. And definitely, I don't even think there was as much usage of the word Cloud Prem until like five years ago. And so this is relatively new, and it has come about specifically because almost all of the larger companies have their deployments all running in one of the hyperscalers, AWS or GCP or what have you. And before, a lot of these companies would actually have AWS deployed on-prem, on their bare-metal clusters, on their bare-metal VMs. And now it's all moved into actual VPCs, just entirely hosted and run by AWS or GCP or what have you. So that shift from running internal compute on a bare-metal system to cloud is what's led to this transformation of the on-prem deployment practices into the Cloud Prem model. What Cloud Prem does essentially is use infrastructure as code. It's a framework, or loosely defined term, to mean that you build your exact stack, but in a specific environment. And in most cases, it's just the Kubernetes environment running on a specific hyperscaler environment. And what has led to the rise is essentially the fact that, because these cloud providers have become so big and so many companies entirely rely on their end-to-end deployment and hosting and all of their operations on these hyperscalers, it is so much easier for anyone that supports one of those environments to be able to deploy a stack that runs locally within their environment, but completely managed and handled and supported by the vendor themselves. So it's a new framework, but it's got its complexities, which we'll get into in this conversation.
Jose:
And maybe just a question. Which then part of the stack is owned by the company that owns the environment? Is it only the bare metal, and then whoever deploys on the cloud, on the private cloud, on the data center, is responsible for everything else? Or do you have the Kubernetes cluster and then it's deployed on top of that? So how is that?
Sam:
Yeah. So let's call them the customer, the vendor, and the provider, the cloud provider. So the cloud provider provides the underlying infrastructure, everything, including Kubernetes itself. You can keep upgrading your Kubernetes environment on a certain cluster that you're trying to run this vendor stack on, and those are some of the things that go into deciding whether a vendor can actually support running their stack in a customer's environment. But who owns what? The cloud provider owns all of the infrastructure, including the VPC or the GKE or what have you. And then on top of that goes the customer's stack, the bunch of services that they have running. And then on top of that goes the vendor's new little stack that goes on top of their Kubernetes setup.
Jose:
Kind of from driving the current shift, I think, and you alluded to it a little bit already before, I guess there's something around the AI workloads coming into the picture, and we'll get a little bit to that later. Any other areas that you've seen kind of drive the usage and interest in Cloud Prem?
Sam:
So one major realization that a lot of enterprises had over the last 20 years is that data is paramount. And with data comes this very serious need and desperate requirement for controlling the data that your users are storing with you, relying on you to store securely, and also just the whole idea of the monetization of it. So data became extremely important, extremely paramount in the hierarchy of the things that we are creating. And from that perspective started a new wave of requirements, which essentially said that all of the compliance requirements around data just got so much harder. So a lot of enterprises had this need for data to continually be inside their geographical locations, or their clusters, their environments, where they have all of the compliance requirements like SOC 2 or HIPAA or whatnot. So all of those enterprises that deal with any kind of sensitive data that they would not want to have shared with a vendor, this model was very appealing, where you have an entire stack running internally, you're storing all of the data. The problem in those cases becomes the delivery of updates into their environment, and the management and the control plane improvements that you have to keep rolling out. So the vendor still has to be deploying into your environment, and that is always a complex process. So I can get deeper into the complexities of Cloud Prem in more detail, but overall, data and the whole idea of its importance and security around it was also what led to the whole idea of Cloud Prem, and the shift from running it on your on-prem systems to this sort of deployment model within the customer's VPC or cloud provider.
Jose:
Thank you. And I would love to go into that part that you opened up around both, I guess, the deployment and potentially some kind of support and upgrading of systems, right? So can you share with us a bit about what's unique about shipping software to such a setup, right? You're shipping it to someone else's environment. As you said, the vendor will need to keep on supporting it and upgrading it. Can you take us through it?
Sam:
Yeah, and it's super interesting and fascinating how we've started to, in some ways, go back in time to those days when we used to have a single laptop or a single Windows computer, and we would get a CD that we would use to install that software or upgrade to a new version. It is kind of similar in a lot of Cloud Prem deployments, especially the air-gapped ones. But the way software updates and software upgrades and delivery work within the Cloud Prem space is, there are two broad categories. One would be where you have a clear separation of the control plane and data plane. The data plane is entirely owned by the customer. The control plane is separate. It's allowed to be controlled entirely by the vendor, so they can keep watching the metrics, how the cluster is doing, if any of the things across multiple services running in the stack are starting to fall apart, or any kind of production fires that are happening within the cluster. So that control plane separation from the data plane really helps a vendor, especially when you're deploying into the Cloud Prem space. But it's actually easier said than done, because there are a lot of different complexities that come about with this sort of deployment. But the other broad form of delivery is what we do in air-gapped environments. When I say air-gapped, it can be a bunch of different things, but you can think of it as a cluster that is running completely isolated from the entire internet. So very sensitive workloads, for example government workloads, all usually require an entirely isolated air-gapped environment. In those settings, the deployment model, or the delivery model, is you package your entire software in charts, Helm charts, and any other form of IaC, and publish it and deploy it, deliver it to the customer, and the customer then has an SRE who installs it. It's just the same way as we used to install software back in the day. And the interesting thing there is, in many such use cases, vendors actually really find it easier to have a forward-deployment model placed in the middle. So a lot of companies who've done Cloud Prem successfully, like Atlassian or Palantir or DeltaStream β there are a bunch of them β but all of these companies had to make a choice whether to continue running this all on their own, or invest in a forward-deployment model where you have forward-deployment engineers going into the customer sites and fully building it out and integrating the system, the stack, in their environment. So that becomes a major place where the complexity comes from, especially in air-gapped environments. And vendors would inherently struggle with setting up calls, sharing screens, and working, connecting their SREs with the customer's SREs and them trying to figure out how to solve issues or upgrade or install the software. So it gets difficult, which is why you will see a lot of forward-deployed engineers being deployed in this space. And AI has just made that so much worse. In the age of AI, everything is everywhere. Everything is just going all across boundaries, and people are struggling to keep track of things and kind of trying to contain it within their environment.
Jose:
Before we get to the AI part, and I really want to get to that, do you have any real-world story that you want and can share with us? It could be something that went really well. It could also be some disaster stories that you're happy to share.
Sam:
Oh, I would have so many, but let me put it in perspective first, because when I say there's a lot of complexity in operating this model, it's really interesting because from a business standpoint, it becomes almost like a losing game. Because what happens is, when you deploy a stack into a customer's environment, they're going to bear the infra costs. So they're still going to have to pay for compute, for memory, for network. So if your stack is not optimized enough, it's going to cost them a lot more money. If your compute or your network is not at its optimum throughput, it's going to cost them so much more money than they have to, than they would be comfortable with. So that is one of those spectrums, or those scales, where things start to get difficult as you try to make your stack better and add features to it and make it more complex. It starts to become bigger and more expensive as a cluster, as a stack that would be using up all of the resources on the customer's environment, at which point the customers start to push back. So that's one big reason why Cloud Prem is not something that everyone would just jump into right away, at least until a few years ago. The other piece is the deployment itself. That is the slowest thing in the pipeline, honestly. The one thing that slows a lot of the deliveries across Cloud Prem is the fact that the customer's environment and the way that they do things needs to work well with how your stack operates. Simple things around that would be like, what is your Kubernetes version? Because the vendor stack, the one that they're trying to publish, that only works with certain versions. And starting with just the version itself, there are so many other things β like for an AI company like ours, you need some sort of GPU inside the environment. And in many cases these conversations start with like, yeah, we can have a stack deployed in two days, and then go on for sometimes weeks or months, because you keep realizing that the enterprises β and Cloud Prem is very much focused on enterprises, so the enterprise deals, and I can talk about that as the next thing. But overall, the environment itself brings a lot of complexity. And when a vendor stack has been built for, you know, maybe three different environments, and a fourth comes along, there's a lot of churn. You either, as a smaller vendor company, have to bend over backwards and support a bunch of different new things that they do internally to be able to win that deal, or just say no and move on and try to sell to other customers. So that is another pain point. So now, the first was pricing β you have to be very careful pricing what you're charging your customer, but also making sure that your customer is not paying way too much in infra costs. The second is this aspect of the environment heterogeneity. And then the third is the very specific applicability of this environment, or this deployment, to the enterprises specifically. That's what makes things harder, as one would expect from enterprises. If it's a small company, they would have one product running in AWS and that's it, and you're done β you deploy it next to their app and it's done. But for larger enterprises, it's way too difficult to get everyone on the same page about how, or what exactly they do. So there's so many unknowns that you have to figure out before you can get all of the answers that you need to be able to deploy into their environment around the β like I said, Kubernetes version is one example, but like exactly how the CI/CD works in their company, and how that's going to affect the delivery pipeline of the vendor stack itself, becomes a challenge. So you have to get everyone that is involved in the same room with regards to the SRE team, the CI/CD, the whole gamut. Those conversations around how and what and where take quite a while for the deployment itself to happen at the initial stages. Once it is deployed, then we start working or talking about monitoring and upgrades and whatnot.
Jose:
And one thing that also you didn't mention directly, but I wonder if that must be the case as well, which is the requirements that it puts on quality, right? I mean, the fact that β I guess if you're deploying something on a Cloud Prem setup, and you just find a bug, or two days later the customer finds a bug, right? I guess that the process of just fixing that bug, or especially then deploying it and fixing it in the customer's environment, is much more expensive than whatever SaaS or cloud infrastructure that you might have, right? So I would imagine that it puts some extra weight on quality, right?
Sam:
Yeah, so updates and maintainability and all of these CI/CD-based flows only add to the complexity. But if you've done your due diligence and have separated the control plane and the data plane well enough, then the control plane deals with all of these updates. You keep finding bugs, you keep sending updates, and it keeps auto-resolving and auto-upgrading on a regular cadence within the customer's environment. So it's so much easier that way. And some of the technologies that are critical in those places are just Helm and, on top of Kubernetes, you have charts β you update your chart, you run a script in the customer's environment, it pulls the right image, deploys it, boom, everything's working again. So all of that works well if you have put in the investment to be able to cleanly do the control plane and data plane separation. And by data plane, I mean all of your data services that run inside the customer cloud are able to store everything exactly as they want within their environment, and the vendor never gets to even see it. So the control plane should never have any sort of interplay with the data that is sensitive, at least.
Jose:
And how do you then, on the monitoring side, right β I would imagine that there's a balance to be had on how much information, telemetry, you're getting from the system, and how that is balanced out with the customer privacy, right? So how do you solve for that?
Sam:
Yeah, so those are the kinds of decisions that you have to make early on. But in most cases, the customer's data remains inside their data environment. But all of the control metrics like Grafana metrics, alerting, all of those control plane statistics are automatically integrated and have an egress out of their environment. So you, as a vendor, have to make some agreements that we're not going to see any of your data, even by accident. But if they want complete 100% security, they just go for an air-gapped environment, so even the metrics can't flow. Their internal SREs, or the forward-deployed engineers that we send, would be the only ones who would be looking into their stack when there are problems. And absolutely no metrics β performance metrics, or CPU and the optimization metrics that you have on Grafana β even those cannot exit their environment in those cases. But in general, most of our customers have been pretty happy with keeping the control plane open while keeping the data plane separate and hidden.
Jose:
Thank you. Thank you for sharing. And I would actually like to finally, as promised in the beginning, get a little bit more into the AI perspective. And maybe starting just hearing from you that you've recently moved to Galileo, right, to focus on AI infrastructure. What drew you there? Why that move?
Sam:
Yeah, great question. So in the age of AI, I was able to quickly realize that a lot of the work that we're doing will eventually be done by AI, with us as the place of accountability still in the pipeline. So a lot of the work that we do is done by us because people trust us, and that trust is not really present in the AI world. But there's no doubt that there will be a lot of work that AI will be doing going forward, while we are just orchestrating and making decisions on top of it. And so one of the reasons why I thought AI evals was a better place was because of the lack of trust and accountability around AI, and the ability to know and have a sense of how your AI is doing at scale across your customers. And AI evals is its own industry at this point. Evals are run by β I think all of the bigger companies already have their eval frameworks internally deployed, all on their own. But a lot of the smaller companies that are just getting started with AI, they needed an AI eval framework, because they have hundreds of thousands of customers and they want to be sure that customers are not going through this negative experience with AI saying something that is completely off or inaccurate, and sometimes even an insult, as we've seen with Grok on xAI. So customers want to be sure, and where AI evals come in is like this layer of accountability, a layer of evaluation that makes sure that all of the interaction that your customers are having with AI deployed on your product are going through some sort of checks and balances and processing that surfaces exactly the one or two conversations that didn't go so well, and why, automatically. So you can't just go around looking for those specific examples where some hallucination had showed up, or some irrelevant question was asked by a customer and the LLM actually started spending tokens responding to those questions. So all of those context-relevance, all of those metrics need to be in place for the customers, for the enterprises, to be able to integrate AI. And that's where AI evals came in. And you can think of it as like a testing environment for AI workloads. And that's what drew me to it. Because if AI is going to take all of our work, someone needs to do the work to put some checks and balances around AI, and that's where Galileo came in.
Jose:
Very cool. Thank you. And how do you see the evolution with β I think, of course, LLMs have been there for a while now, but we've been seeing some evolution of the self-hosting part of LLMs being kind of more and more relevant, with the models getting smaller and smaller. Are we already there where self-hosting an LLM is the obvious choice, or are we getting close? How do you see that?
Sam:
So self-hosting is still extremely expensive. And that's not because of the models themselves. It's because of the GPUs that they have to run on. And the hardware is one of the main bottlenecks for being able to run your models internally. Also, what's super interesting in terms of trends that we've seen in the last year or so, or two, is that the open-source models are just months behind in terms of intelligence. Sometimes they even break the thresholds of the frontier models, the closed-source models. So, open-source models β and by the way, the only models that you can really self-host are the open-source models and not the closed-source models. And the closed-source models, the frontier ones, are always at the forefront of intelligence, and are razor-focused on achieving AGI, whatever that means. But the gap, you're right, is ever-shrinking, ever-receding. And what's interesting is, the models β for the same amount of intelligence that you used to get three years ago, you can now get to run on your laptop. And it's not that hard. So the hardware is upgrading, the intelligence and the sizes of the models, and also their operation itself, is shrinking. So we are moving to a place where we would have very powerful models, very intelligent models, deployed locally. But at scale, I think it's still a few years in the future. Because maybe β and this is just me thinking out loud at this point β perhaps it has something to do with the usage of the frontier models and our reliance on that level of intelligence, that makes us undervalue the less intelligent models that we get now, that are just as intelligent as the frontier models two years ago. But we just don't want to use them because we're so used to the Opus models now. So,
Jose:
so although two years β a lot, a lot changed in the frontier models in two years, right? So it is going a little bit.
Sam:
Exactly. But then again, some new architectures have also come about, with the mixture of experts lowering the operational requirement for these models to be a lot smaller than the actual model size. So sometimes the models are like hundreds of gigs, but the actual runtime usage is just 40 gigs of RAM. So it's a lot nicer now. And from a Cloud Prem perspective, it is definitely something that a lot of enterprises are exploring and, in fact, are relying on, especially from my experience, because we don't directly work with models themselves, we work with eval models. So we have an in-house model that we developed that is an evaluation model, which evaluates for a certain set of metrics. And that model is built on top of open-source LLMs out of larger companies. So in that realm, the companies that we're working with have been very open to evaluating the model outputs from frontier models, but with our small internally deployed model. And that's where the big difference comes, because as soon as you start going down the self-deployment of AI models, you stop paying infinitely for the tokens that you use. And it's just getting worse and worse. If you had an Opus-like model that you had running internally, you would probably be spending $3 million a month just to run it for your internal customer users β but it's just going to be 3 million, it's not going to be based on usage and how many users are getting how many tokens and whatnot. So the whole tokenization and the payment mechanism around it is causing a lot of pain across the industry, where recently this news came out where Meta is planning to lay off 8,000 people because they need to be able to continue affording AI, because AI is so expensive. So, yeah, make what you wish of it. But it's still far from fully being deployable internally for smaller companies, but something worthwhile for a larger enterprise.
Jose:
Yeah. And so, maybe two β I think we're getting towards the end, but just one final question on the AI, and then we just have a couple of rapid-fire questions. So if a large organization is coming to you today, maybe tomorrow, saying, OK, I really want to self-host AI β I don't know if they come in directly with that question, but what is the guidance right now? Is it to find the balance, and in some cases you can self-host because you have something that is good enough for that? Or is there β I don't know, maybe there isn't a short answer.
Sam:
So if you ask any AI consultant whether you should run or deploy your own internal model, the answer is going to be sure, but it's going to cost you. And there's an immense, very terribly limiting shortage of GPUs right now. Just no one has enough GPUs, even Google and AWS. When you go to their website and you try to select a node that has some solid GPUs, even if you commit to a few months β and first of all, they force you to commit to a certain number of months for it to make it worthwhile for them, because they want to prefer customers that are going to continually use it and make it financially viable for them. So there's an immense shortage of GPUs. If you have enough GPUs to run, it's still going to cost you an arm and a leg for being able to deploy larger models internally. And then on top of that, you can layer the costs of running it, of inference, of the actual complexity of continually debugging and fixing and upgrading β it gets too much. So it's only relevant, at least at this time, for the larger companies that can afford it. With that being said, I wanted to address one of the questions that you had asked earlier β why AI is making Cloud Prem so much more important now than before, and why is everyone talking about Cloud Prem? And the reason for that is, if you've seen the way we operate with AI, the AI is a thinking partner. So it has the most sensitive data that you can think of. If your AI model is β let's say Mark Zuckerberg is talking to their AI model, and if Anthropic's listening, even if they're not trying to train models on what Zuckerberg is saying to his AI partner, it's still pretty risky for those conversations to be in another company's environment. So there is an immense need and a lot more focus on Cloud Prem to be able to either fully β so, one layer you cannot remove is the frontier models. So a lot of companies now are making those enterprise deals with the larger model providers and agreeing that no one's going to look at their data, like all sorts of data governance and data security agreements. But aside from that, you don't want vendors who are helping you upgrade or enhance your AI experience to also be in the middle path of reading through your data. So that β and imagine this, the kinds of things that we're discussing with AI, especially when you're vibe coding or whatnot, AI can even see all of the keys that you have stored on your computer, because it has access to your CLI. AI basically has access to everything. And so if you had a database in the read and write path to your AI model provider, then that database would be storing all of these things. And in the latest models, what I've seen is Opus β Claude Opus now gives you a clear warning, "this key I have seen, you should probably rotate it," because that is the first interesting development. But there's so much sensitive data that is going through the AI pipeline that a lot of companies want only the model provider, maybe, to have access to that data, because they can't help it, because they own the intelligence layer. And then themselves β no one in the middle should have the access of that nature, of that kind of sensitivity. And that's why Cloud Prem has just been the norm for a lot of enterprise customers to want to integrate AI into their products.
Jose:
That makes sense. Thanks a lot. And so we're getting to the top of the hour. I'll just do very quick rapid-fire questions. First one: is there a book, podcast, or thought leader that you would recommend to our audience?
Sam:
I really keep going back to this one book that I very highly regard, called β actually, two, but the top one would have to be Designing Data-Intensive Applications by Martin Kleppmann. Absolutely iconic. And it's important to realize that, yes, there is this whole AI revolution that is happening, but what that book covers is still what runs the world, what gets everything done β the guarantees, the deterministic nature of software, of distributed systems, and the research that has gone into all of the things that are covered in that book are existing. And AI compared to that is just an interaction layer on top. And it helps us understand a lot of the things that are happening, because it is removing the barrier of understanding and knowledge to some respects. But everything that that book covers is so relevant today, more than ever, that engineers in the next generation should absolutely not miss it and not over-saturate on AI workloads. And always, always remember to keep your distributed systems knowledge up to date. Podcast β I don't know, but I have a blog myself where I post some interesting ideas and articles, called just my name, samdar.com, where the blog is The Distributed Mind. So if people want to stay in touch, say hi.
Jose:
Awesome. Thank you so much. And final question. To you, scalability is?
Sam:
Paramount. Because β let me take a second to elaborate on that. It's so important because business itself is only viable when it's scalable. So that's how important scalability is. And there is an explosion of apps these days where everyone's building their own little app to do their productivity stuff, right? And that's great. But if you're trying to monetize it, you need a lot of people to come together and use it. And when you have a lot of people, you need scalability. So business equals scalability in a lot of respects.
Jose:
That's a wonderful way to wrap it up. Thank you so much, Sam.
Sam:
Thank you.
Jose:
And that's it for this episode of the Smooth Scaling Podcast. Thank you so much for listening. If you enjoyed, consider subscribing and perhaps share it with a friend or colleague. If you want to share any thoughts or comments with us, send them to smoothscaling@queue-it.com. This podcast is researched by Joseph Thwaites, produced by Perseu Mandillo, and brought to you by Queue-it, your virtual waiting room partner. I'm your host, JosΓ© Quaresma. Until next time, keep it smooth, keep it scaled.
[This transcript was auto-generated and may contain errors.]