Guests: Jon Hill | Brian Seguin
Company: Linode | Stark and Wayne
Show: Let’s Talk

When Jon Hill, Vice President of Revenue for Linode, and Brian Seguin, Chief Operating Officer at Stark and Wayne chat about capital-efficient stacks, they mean business.

Defining capital-efficient stack

So what exactly is a capital-efficient stack? When asked that question, Hill stated simply, “A tech stack that’s really capital efficient is one that, as it scales the same cost or the cost per unit decreases.” In stacks that are not capital efficient, the more they scale the more they cost. This rising cost doesn’t come on an overall basis, but on a per-unit basis, because they’re potentially getting more complex.

Check out the whole discussion on YouTube:

Seguin has a slightly different take on the subject, when he says, “I think having a capital-efficient stack is making sure you have the right balance of the appropriate human capital element with the right software and IT and compute spend.” He clarifies this by citing an instance of how a lot of companies scaled during the pandemic by just adding more tech resources to solve the problem, instead of “really trying to dig in and solve what the actual software problem is or getting the right software to be integrated appropriately.”

Three components that affect capital efficiency 

Three factors affect capital efficiency: technical debt, costs, and tribal knowledge. Seguin jumps in to address the tribal knowledge issue when he says, “A lot of the companies try to fix the whole tribal knowledge thing with documenting and making sure that everything is documented, but that only goes so far.” He points out that when you’re building your tech stack, you want to use well-documented things, which will help alleviate the tribal knowledge issue.

Hill points out that businesses need to make sure to have appropriate padding on the technical team, to make sure there’s room for people to cross-train, and to always be hiring ambitious juniors who want to move up in the organization. , “…those juniors will be ambitious and they will want to tackle some of these goals and things. And they will want to learn all that tribal knowledge so they provide more value to the company. Because tribal knowledge is inevitable,” explains Hill.

As to costs, Brian points the finger at scaling when he says, “People just keep spinning up more and more instances and just aren’t even reigning anything in. And I think now’s a really good time to start looking and auditing what has been done to scale very quickly over the last year and a half.” On this matter, Hill adds, “The idea is like, okay, we got a little ahead of our skis there. And we took a step back looking at, okay what are we really trying to solve for here? How do we do this?”

In the end, it can boil down to getting the right architecture in there to make sure things are being constantly reevaluated. This all begins with building the right team. Seguin brings up the point of how, when starting from scratch, a lot of people will default into “you need to do agile scrum and the pairing model one hundred percent.” They have found, however, in practice that agile scrum only works to an extent and that the agile scrum model is a theory that needs to be adapted to business goals. Seguin also believes it’s about getting a mixture of people in DevOps that can transcend boundaries and that every single developer is going to now need to be able to take on an operator role as well.

To this, Hill adds, “We don’t see a lot of bureaucratic red tape that’s happening, at least for us in the highest performing teams. They know what they’re looking for. They’re equipped to solve problems that come up because let’s be honest, we’re building applications.”

Tips on building capital-efficient software stacks

Both Hill and Seguin offer tips for building capital-efficient software stacks. Seguin starts by saying when you’re looking at multi-cloud, it all depends on how large your workloads are. If you’re a Fortune 2000 company, you’ll probably want multi-cloud. But from a normal business operations standpoint, there’s not a huge need for multi-cloud. He adds that businesses “tend to use a screw for every hole instead of nails for the right holes and screwing the right parts together.”

It’s also important to be intentional on how you choose the right architecture for the right job and the right outcome. Furthermore, Seguin brings up data gravity, and how it must be a primary concern when constructing architecture.

Seguin also states that you must be able to tie your business value to whatever tech expenditure you’re putting on things. He says, “If you can do that from day one, it will naturally be capital efficient because when you’re getting new features and things, and you’re getting new applications and you’re getting new data services put on, you’ll actually have the business value tied to that.” He adds finally, “You do need to document your important decisions and you need to keep your documentation up to date, but by the  same token, you also need to have someone going through your code and reviewing it to see if there’s anything that they can remove out of it.”

The summary for this interview/discussion was written by Jack Wallen

Here is the full, rough transcript of the discussion:

Swapnil Bhartiya: Hi, this is your host Swapnil Bhartiya and welcome to Let’s Talk Business/ Today we have with us two guests, Jon Hill, Vice President of Revenues for Linode. And once again, Brian Seguin, Chief Operating Officer at Stark and Wayne. Jon, Brain, it’s good to have you both on the show.

Jon Hill: It’s great to be here Swap, thank you.

Brian Seguin: Thank you for having us Swap.

Swapnil Bhartiya: This pandemic has kind of made a lot of startups question the whole growth at any cost approach when they are building their company. I mean, the pandemic has changed a lot of things, not just one thing. But when we are building a new business, whether your end goal is to build the next Amazon, Microsoft, or Google, or simply to sell it, there are certain things you have to, in today’s world, very carefully plan your tech stack. There are a lot of pitfalls that you have to avoid, which can turn a promising business into a blip on a startup’s radar right? So irrespective of what the end goal is, I think today what we will talk about is the importance of building a capital efficient business. So if I throw this question to you folks, what do you mean by capital efficient stack?

Jon Hill: From my standpoint, right, leading revenue at Linode, I speak to a lot of different customers. A lot of our customers are already on the cloud. And one of the things that we hear about is they’re trying to kind of unwind what they’ve created, because it’s just become really expensive for them in the current market. So a tech stack that’s really capital efficient is one that as it scales, kind of scales that same cost or the cost per unit decreases. Where a lot of times when you see on some other cloud providers, that’s not the case, right? The more they use it, the service, the more it costs them, not on an overall basis, but on a unit basis because they’re getting more complex potentially.

And so taking them back to square one, just thinking about, okay, if I’m going to create a new workload and app, what have you, how do I build this with that future in mind, knowing that, is this thing going to cost me several million dollars to maintain? Or can I do this in a way that as I grow, my cash flows can compensate for the costs of this tech.

Brian Seguin: Yeah. And I think I have a little bit different perspective on this question. I think that having… I agree with what Jon’s saying, but I think having a capital efficient, from a tech stack standpoint is, making sure you have the right balance of the appropriate human capital element with the right software and IT and compute spend. Sometimes what we’ve seen during the pandemic is a lot of these companies were scaling with just adding more technical resources to try to solve the problems, instead of really trying to dig in and solve what the actual software problem is or getting the right software to be integrated appropriately.

Swapnil Bhartiya: One more thing is technical debt we also have to worry about tribal knowledge. Where some teams they do know about certain things, that’s how they fix the problem, then they move out. No matter whether your condition or whatever it is settled, you’re stuck there. So can you also talk about some of these flags that you should be worried about? It’s very easy to put your credit card and start putting things, but sometime you end up, you can buy a mainframe for the cost of a public cloud. So talk about these three factors because you’ve also talked about human elements. So I do want to talk about costs, technical debt, and tribal knowledge.

Jon Hill: Yeah. I can jump in kind of start. Right so Linode being a cloud provider, we kind of are intimately in this space. One of the things that we really strive to do is always recommend open-source or third-party tools to customers when they kind of ask our advice. Open-source, first and foremost, just because that knowledge is there and it’s not necessarily proprietary, right. Understanding the specifics of a service on AWS or GCP while they’re powerful, can be really complicated and not everybody understands that. Or not every company can afford to hire an AWS certified engineer. So we really default to starting with open-source first. And if you can accomplish your needs with open-source, well now let’s step up to that next level of third party tooling. And then that’s where someone like Brian [inaudible 00:04:30] Stark and Wayne, where they can really help kind of consult around, all right how do you take this to the next level, if you’re going just beyond open-source. And not to say that Brian can help with open-source as well.

Brian Seguin: Yeah. It’s a very interesting question. When you talk about costs, technical debt, and tribal knowledge, you want to make sure that you’re always… A lot of the companies try to fix the whole tribal knowledge thing with documenting and making sure that everything is documented, but that only goes so far. As what Jon’s saying about using open-source tooling and things that are very easy to use and ready to use out there, hopefully the documentation is actually outside an exterior. So when you’re building your tech stack, you want to make sure that you’re using things that are well-documented out there from wherever you’re consuming the technical IP from. Then that’ll help combat some of the tribal knowledge things. But I think a lot of the tribal knowledge that’s mainly issues is less on the configuration side of things and potentially more on the actual business operations and business IP, and business logic.

And from that standpoint, you just want to make sure that you have appropriate padding on your technical team, as far as making sure that you have room for people to cross train. You’re giving these people the time to cross train and make sure that you’re constantly getting in juniors who want to move up in your organization so that you’re always having people that are ambitious and wanting to make sure that they’re contributing to the company and the company’s goals. Those people, I think one of the things many companies make a mistake on is not hiring juniors in sooner than later, because those juniors will be ambitious and they will want to tackle some of these goals and things. And they will want to learn all that tribal knowledge so they provide more value to the company. Because tribal knowledge is inevitable.

And then from a cost standpoint, I mean costs, I think during the pandemic, I’m sure Jon, you’ve seen this too. People just keep spinning up more and more instances and just aren’t even reigning anything in. And I think now’s a really good time to start looking and auditing what has been done in order to scale very quickly over the last year and a half. And yeah. But yeah, Jon, what do you think of that?

Jon Hill: We see a lot of people doing that. Like they’ll start to spin up a lot of services and then you’ll see them start to maybe pull them back a little bit. And from a customer success standpoint, when we start to talk to them, it’s really, the idea is like, okay, we got a little ahead of our skis there. And we took a step back looking at, okay what are we really trying to solve for here? How do we do this? We happen to be on the positive side of that is, through the pandemic we see a lot of people starting to say, Swap kind of, as you started with like this growth at all costs mentality just doesn’t really work, in really kind of any future environment for that matter for some businesses.

And they’re kind of starting to say, all right, how do we do this? Not to be cliche and talk about multi-cloud, but they literally are saying, all right, how do we start to take kind of best of breed approach? And let’s look at our workload, what can be parsed into potentially separate components that can run somewhere else and it’s cost effective, but without sacrificing our end user experience? Whoever that is, whether it’s an internal user or an external user. And that’s a tough thing to do to, to go through that. And I really admire a lot of the CTOs and the architects that we’re working with, who were taking that challenge head on to really figure out, all right, how do we take this thing apart? And re-craft it for the next 5, 10 years of cloud? Where we just came from kind of building on one cloud.

Brian Seguin: And that’s a really good point on the technical debt standpoint because, getting the right architect in there to make sure that things are being constantly reevaluated for, can we get rid of this service? Can we trim here? Can we trim there? That’s a really important thing to do to mitigate technical debt.

Swapnil Bhartiya: You folks have talked less about technology, but more about people. So I do want to talk about cultural aspect of it. If you do know the both companies, every company likes to say, hey we have a unique culture, but we do know the kind of culture that Linode has, there was some impressive things and that kind of culture [inaudible 00:08:49] has. So if we just focus on culture for a bit, for when we are building a new company, because all these things, whether you talk about tribal knowledge, technical debt, or even if you, we are trying to break silos, but we are creating new silos, right? With SRE, DevSecOps, and all those things. So what would be your kind of, not the whole playbook, but when somebody’s built their new business, before we talk about how to approach tech stack, I want to just quickly focus on how to build the teams itself so that you have that culture where you can move faster securely, safely, without either creating or inheriting technical debt.

Brian Seguin: Yeah from a team dynamic standpoint, if you’re starting from scratch, a lot of people will default into, you need to do agile scrum and the pairing model a hundred percent. But what we found in practice, the agile scrum model works to an extent, but the agile scrum model is a theory that needs to be adapted to whatever your business goals are. So it might not, the actual textbook practice of the agile scrum model can be adapted to your organization and that’s what it’s kind of designed to do. But a lot of people just try to do the textbook standpoint.

So I think that’s an important thing, but I think also getting that mixture of the DevOps people, the people that do transcend those boundaries and can do a little bit of the programming along with the DevOps. I think as the industry is changing more to consuming containers, every single developer nowadays is actually going to need to be doing that operator role. They’re going to be needing to containerize their own code. So it’s really important to make sure you have that foundation and have a good DevOps person to back up those developers.

Jon Hill: Yeah. I think the other thing that I would add to that, Swap, is that for the teams that we work with, leadership has been really clear about what problem they’re trying to solve. What does that end look like for them? And they are enabling that team to make that decision, to make decisions on how we get there, how to solve that problem. We don’t see a lot of bureaucratic red tape that’s happening, at least for us in the most high performing teams. They know what they’re looking for. They’re equipped to solve problems that come up because let’s be honest, we’re building applications. We’re in cloud. Problems always come up, they’re equipped to handle them. They’re enabled and empowered to handle them. And those teams just, they have an ownership and they feel like they own, and there’s pride in what they’re putting out there to their company and their users.

Swapnil Bhartiya: Talking about ownership, and as we were talking about multi-cloud earlier, sometimes multi-cloud is kind of strategically planned as sometimes because you don’t build gates, you’re building guard rails. Different teams can go and do whatever they want. So sometimes they pick the cloud they like and then you end up with a multi-cloud or, through acquisition, you end up with a multi-cloud history, which is not very coherent. And so are so many things, so many moving pieces. So if we go back to the tech part, and switch from the cultural aspect to the tech aspect, that if you want to build capital efficient tech stack, what are some of the things that you should be looking at? And let’s just have a very holistic view of where we are talking about security. Of course you are giving them guard rails, but there should be something in place so that not everybody is doing things like the way it should still be a coherent story within an organization.

Brian Seguin: Yeah. I think when you’re talking about using multi-cloud, I think that many organizations feel the need to use multi-cloud and they don’t actually need it. It really depends on how large your workloads are and what you’re actually intending to do. If you’re a Fortune 2000 company, you probably want to be multi-cloud for different reasons if you’re a startup. Startup companies tend to want to do multi-cloud, if they’re a SaaS offering and they actually want to do offerings to multiple different cloud infrastructures. But from normal business operations, there’s not a huge need for multi-cloud. And what we’ve actually seen is some organizations, some of the smaller organizations, that try to adopt and use multiple clouds, or they do that because one person on the team insisted on this one IS, they have to also take into consideration what’s the barrier to entry for someone to learn that cloud and can they get other resources in to learn that cloud, can they maintain that over time?

And what we’ve actually seen as sometimes when the people with the experience leave that was associated to that one infrastructure that was driving for the multi-cloud, they need to actually hire a consultant to help bring that over into conformity with the rest of the team. And I think that’s an important thing because a lot of companies go all in with one tech stack and just say, hey this is everything that we have to do or have to use and we’re just going to use everything that this one tech IS offers.

But what they actually really need to be doing is taking a look at their solution, and I think Jon, you and I were talking about this. They tend to use a screw for every hole instead of nails for the right holes and screwing through the right parts together. They’re not taking a look at the architecture and taking an actual cloud native architecture approach. They don’t need multiple clouds. What they actually need is some data services that are separated out differently from the IS provider. Then you can actually, if you can move your data, you can move your cloud really, because containerization of applications is trivial. Sorry. That was a long-winded answer. But Jon, what do you think?

Jon Hill: Yeah I think there’re a lot of, Swap like you mentioned, like there’s a lot of just accidental multi-cloud because people have just started using different clouds for different workloads or requirements because of whatever the reasons are. They like that, they got a better deal there, what have you, right. There’s a ton of that. I think Brian, what you’re talking about there is the intentional multi-cloud. We’re architecting a stack and we’re thinking about how is my stack portable, not necessarily how am I leveraging the best services available for my current cloud provider? And multi-cloud means different things to different people. We see, I think there’s a lot of great things that are happening with multi-cloud just taking things and moving it to quote unquote, the edge, right? So that we have either more of redundancy or we’re closer to the end user, so we can have better latency.

Those are multi-cloud. And some of these platforms out there like a Macrometa, for example, they do a really great job of helping to distribute your workload across multiple cloud providers, without you even knowing it, right. So if you adopt something like that, that can make more sense as a multi-cloud strategy. Or potentially it’s looking at, okay how do I isolate my long-term storage from my short-term storage from what’s needed right now in the moments, right? And maybe Glacier is an amazing thing for you to use for your long-term storage. You never really get to, but you’re keeping it for requirement’s sake.

But for short term things and things that need to happen right now for this workload, well, maybe I’m going to [inaudible 00:16:05] on someone like Linode or I’m going to be using a bare metal provider, or maybe I’m using Hetzner or what have you, because I need that. And so being really intentional about how do I choose the right architecture for the right job and looking for the right outcome, is something that is not trivial. People just really overlook that in my opinion. And I think there’s a lot of advantage that can be had there, particularly from a capital efficiency standpoint.

Swapnil Bhartiya: You also have to worry about getting locked into a particular vendor because prices may be good now, but once you get locked in, you are at the mercy of it. So how much should they care about data gravity as well when they are trying to build their tech stack, which is capital efficient?

Brian Seguin: Data gravity has to be a primary concern when constructing your architecture. And this is why I’m going back to Jon’s point that you really need to have an open-source first strategy, especially when it comes to data. If you can own and operate your own data services, that’s likely worth the investment. Because then you are multi-cloud, then you can migrate to other clouds, then you’re not locked in. I know some people that cannot even test their backup and restore functionality on their cloud provider because the actual cost of pulling in and out of the storage buckets is actually a huge critical impact for the business. And it removes the business value that the application actually does. So you want to make sure that you’re architecting things in a way that you can still test your backups. You can still expend more on compute and not have to worry about the bill at the end of the day.

Jon Hill: Yeah I 100% agree. Data, this is the big thing, right? It’s expensive. Once you start to amass data in one system, it inherently creates a lock-in. And that necessarily isn’t a bad thing if you love where your data’s locked in, but it could be depending on what your goals are and it’s expensive and timely to move data around. So that’s something you need to think about. There is no really pretty clean answer there, except do your due diligence and your homework. Don’t just do what your current cloud provider says you should do, because they’ve made it easy for you quote, unquote. Look around. There is a ton of providers that provide a lot of different data services, whether it’s storage or transformation services, there’s a ton of stuff. New things are popping up every single day.

So it behooves you to always keep your ear to the pavement and know what’s going on there. Yeah attend conferences, virtual or in person, right. Pay attention to what’s happening on hacker news and those types of things, right. And just listen for what’s going on out there because people are really combating this and there’re some great new tools coming to market that could help with this. But if you just focus on putting it in my own version of whatever S3 I have, like that could be really painful for your business. Two, three, four, five years from now.

Swapnil Bhartiya: If you look at, purely from building a capital efficient tech stack, what would be your, either steps or kind of playbook or advice, so this is how they should build a capital efficient tech stack from the very beginning?

Brian Seguin: If you’re really starting from scratch, the biggest thing that you need to do to build a capital efficient tech stack is you need to be able to tie your business value to whatever tech expenditure that you’re putting on things. If you can do that from day one, it will naturally be capital efficient because when you’re getting new features and things, and you’re getting new applications and you’re getting new data services put on, you’ll actually have the business value tied to that. So you’ll actually have your managers, who are trying to make these business logic decisions, equipped with the right information to make the right decisions for the company, for the long haul.

I guess another piece of advice is, you do need to document your important decisions and you need to keep your documentation up to date, but by the same token, you also need to have someone going through your code and reviewing it to see if there’s anything that they can remove out of it. Or if there’re any applications that are unnecessary. And that constant reevaluation of code and rehashing things, is important because that helps to eliminate future technical debt. And that person can also start to assess some of the other architectural things and needs as they’re going through assessing things.

Jon Hill: Yeah. I would say we recommend similar for our customers. When they come through, it’s really looking at it understanding, okay what are you spending? What is the workload? What is the importance here? Is there a better way? We always tend to recommend open-source technologies because we find that yes, you have to manage it yourself. But removing that management costs adds, potentially, a cost savings, right? You have to understand that now your time is going to manage that. And you have to understand what that calculation is from an hourly rate standpoint. But a lot of times it could be a lot cheaper. Particularly if you’re going to use solutions like, Galera right? Setting up Galera, managing Galera, it could be a heck of a lot cheaper than running it on another type of manage database platform. But Galera might not always be the right solution for you. So you have to look at those things and understand, where do I have opportunity? And does this align with where our business is going in the next three, six, nine, twelve months, what have you?

Swapnil Bhartiya: If you already have infrastructure in place, there are a lot of things which are not efficient, so how to fix them to make your stack capital efficient?

Jon Hill: I think the first thing is just take in inventory. Okay, what are the workloads that are running? Let’s look at what is the infrastructure that’s powering those, what’s the software we’re using to handle that? And then look and see, okay have that basic thing. Is there a better way? Why are we doing it this way? Is it just because, and that’s how it was set up N number of years ago? All right, let’s take a look at this. If it’s still running fine and we don’t think that there is a better way, then great. If it ain’t broke, don’t fix it. However chances are, when you’re looking at those things in isolated components, you’re like, okay there might be a better way of fixing this with this new thing that came up or this open-source project has evolved to a point now where it makes more sense for commercial feasibility standpoint.

And then you look at, all right, if we were to replace that piece with this new piece of technology, what does that mean downstream? What does it mean to downstream of other workloads that talk to that? Right. Okay. We’re going to have something break down there. Is this a project that we think is going in the right direction or is it going in the wrong direction, and it’s going to cause some more headache. You just start to look at those different things. And if everything starts to be like, yep, makes sense. Right. There’s a better way of doing it. It’s more cost-effective. It plays nice with the other technology we have. It’s only improving based on what we’re seeing. To me, it feels like it makes sense to put a couple of sprints together, figure out how do you flip that around and off you go.

Brian Seguin: And I would say a couple of easy quick hits that you can do is, empower your developers or your technical staff, to start logging problems. Start logging areas for potential improvement. And then you can assess those and prioritize them in a way that you can have some quick wins on the easy ones first, and a long haul for some of the bigger ones that need to change. A lot of companies get caught up in saying, what do we do first? And some of them say everything. Some of them say nothing. But the biggest thing is to try to figure out what your biggest business impact ones are first, obviously. But a lot of times those biggest business impact ones take a long time to fix. And that’s okay. So I’m actually recommending, you want to solve a lot of the smaller pain points first, so you can start getting momentum and people feel good quick wins, and you want to make sure that you’re getting those good quick wins with different improvements over time. And you’re giving credit where it’s due in the different technical teams.

Jon Hill: Yeah for sure. Like if you’re using some kind of planning tool, like understanding level of lift and level of impact, those two matrices where it’s low level of lift, high impact. I mean, those are the first things you take off the box, right. But you can’t ignore the high lift that takes a lot of time. You just have to plan for that, right. If that’s going to take you the better part of five, six, seven months, well, you’d better get started now, right. And think about how do we distill that down into sprints and off we go.

Brian Seguin: Yeah. And I think the other piece too, is to ensure that you’re getting your team a diverse… Or a diverse community to work with. You want to make sure that they’re seeing perspective at conferences or even on TFiR, all the different perspectives that they can get. And they might actually find other solutions out there that exist that they hadn’t even thought of. Or they actually might see a solution to a problem they didn’t even know was a problem. And I think seeing that diversity and seeing the different information flow, I think is extremely important.

Swapnil Bhartiya: Now you have kind of now looked at how to build it from day one. You also try to fix a problem that you might have. But this is always a journey. This is not a destination unless suddenly you just sell the company and move on. So we also need to kind of build a longterm strategy so that you not only are, but you remain, capital efficient over time for whatever your end goal is. What would be your advice for that? I think goes back more to the culture and processes than actual tech stack.

Brian Seguin: Yeah. I think the biggest thing is to, as you’re reading different practices, know that everything has to be malleable because your business is not going to be a perfect fit for any of these strategies that are out there. And there’s going to be customizations and things that are going to need to be done either to technology or to the culture or the process. I think that’s really important. I think the other thing that’s really important is ensure that your teams, as you’re going through any of these evaluation process, actually has the time to do the things correctly. A lot of times, we get caught up in having a lot of company grade meetings and company events or practices, or what have you. And what we actually find out is, some of these companies are giving these technical resources 40 hours of work a week from a technical standpoint, but they’re also expecting an additional 15 hours in company policy or company activities or things like that. So you actually have to make sure that you’re sizing your teams appropriately and you’re not cutting those things out.

Jon Hill: Sure. Yeah. So my answer would definitely, understand that I’m not a developer, right? So I can’t speak to some of these things. The one thing that I do see in this space is, for businesses that are looking to sell, right? At some point in time in the future, if that’s their goal, and even if it’s not right, this industry is still somewhat small. So think about your legacy, right? Knowing that you’re going to be working at this company, you’re contributing to their code. You’re contributing to their products. If you get acquired, new teams come in, people are going to see your work. They’re going to understand, what were you building? What was your thought process? Make sure it’s well documented because that becomes potentially your next opportunity. You never know who you’re going to meet or need to speak with five years on the road, if they happened to interact with what you’ve built before, and they can tell it’s really thoughtful. It was well-documented at the time. It was taking advantage of the best practices or emerging best practices of that day. That bodes really well for you.

So legacy is important in this space, particularly in this small world, at least in this cloud world while it’s still a lot of people in it. It’s not that big. So just think about that. And that could really, I think, personally drive a lot of things forward. I mean, that’s the point, right? Like people look at these large hyper-scaler providers as the hammer for every screw when it’s like, just take a step back and think about it and be like, okay what is the right tool for this job? Maybe it is within my hyper-scaler world. Maybe it’s not.

And a lot of people are just blinded to that, right. Because, oh we have credits. Well credits expire, and that could lead to really a false sense of, we can afford this, when really when those credits expire and you’re on your own, that could be really, really difficult. So yeah, thinking about it from that standpoint, do you have a hammer in your hand and you’re trying to solve a problem where you need a screwdriver? That’s an important perspective that not everybody has. I think that goes a long way in just ensuring that you are going to at least keep capital efficiency kind of in the forefront of your mind.

Brian Seguin: I think you really hit it really well there, Jon, when you said the credits. Because I think that a lot of organizations mistake the credits in when they’re doing their calculations for business value. And they might not actually want the software to work… They might not actually want to proceed with developing the software because they’re seeing all these profits, but the profits are only because they have the credits on. And when the credits go away, it’s actually going to be a loss leader for, for the organization. And I think that’s definitely important.

Jon Hill: And then understand, you’re burning credits when you’re not at any real level of scale. Once that thing starts to hit scale and you have egress charges and you’re dealing with different cloud costs in different regions, that could be a really painful world. And you don’t really have the luxury of time to figure out how do I solve this problem then. That then becomes a kind of a roof on fire moment. Whereas if you take the step back now and just, as a technical co-founder, or as that DevOps team, how does this scale? What happens when we reach 10,000 users, 100,000 users, 1,000,000 users? What does that mean to my business, right? And we set up because if you just go blindly into that, you for sure know that conversation is going to come your way at some point in the future. And if you’re not prepared for it, that’s going to be really difficult.

Brian Seguin: And care about what it means to have those 10,000 users. Instead of just saying, this is going to be my problem or someone else’s problem years from now, care about what it means so you can actually follow through. Because if you’re caring and you’re planning into the future, playing the long game. That’s what your mentality you always wanted to have to create a capital efficient tech stack.

Jon Hill: Totally, absolutely. And what CEO doesn’t want the business to be capital efficient, right? It means I can raise more money at a higher valuation. I keep more of my margin, so I’m making more money. And then when we do go to sell, if that’s the way, you get more money from it. Like it only helps everyone involved.

Swapnil Bhartiya: John, Brian, thank you for joining me today for this discussion about how to build a capital efficient tech stack, thanks for the discussion. I would love to have you guys both again. I think that yes, you guys should come together so we can talk more often on camera as well. It’s a good team.

Jon Hill: This is great. Thank you very much.

Brian Seguin: Sounds like fun. Thank you for having us Swap.