Episode Transcript
[00:00:04] Speaker A: Welcome to the Subscription Heroes podcast. I am your host for this episode, Baird hall, one of the co founders here at Chernkey. And this is a special edition of the podcast. We're trying something new. Hopefully this catches on, but we're calling this for internal use only. And this is a version of the podcast where you, the listener, get to come behind the scenes and hear the Cherokee leadership team talk about the current topics and trends that are most important to SaaS founders and operators. Today's topic is building versus buying within the SaaS industry. And we've got Jay Nathan, our COO, and Nick, our founder and CEO, joining to weigh in on the topic. So without further ado, let's jump in.
All right, so the topic for today is build versus buy in SaaS. I think we'll talk about all different SaaS companies. Large b, two b, two c, bootstrap. I think we've got a lot of experience across different company types, and it seems like the build versus buy discussion all kind of starts there based on how companies are thinking about it. Everybody thinks about it a little bit differently, and it keeps coming up with our customers. So we've decided to have a quick internal chat about it. And also the output of this is going to be a landing page that helps walk our customers through how to think about building versus buying in SaaS. But, Jay, you've been in SaaS longer than most of us walk us through. Just like high level set the stage for, you know, maybe we have some new operators listening that don't know what this means. What's it mean to build versus buy? And kind of how do you see teams thinking about this from a high level?
[00:01:35] Speaker B: Yeah. So in the olden days, like, everybody used to do build versus buy kind of evaluations, even internal it shops be like, well, should we create something? When I first started my career, I worked in a big enterprise it shop, and we built a lot of stuff. Actually, the team that I was on, we built like 700 applications and had to maintain all of them. Right. This is like in the late nineties, early two thousands. And so building versus buying was a very typical kind of thing, even for a non tech company. But I think today, the 700 applications that we had 20 years ago or 20 some years ago, there's probably a SaaS application for every single one of those products that we had built and maintained ourselves internally. We had a big team to maintain that much software, and some of it was mission critical. It was actually a utility. So nuclear power plants is what I was supporting. But now one thing that's unique for our go to market is one segment that we go after. Probably one of our most critical segments today, or the segment where we have the most critical mass, is B, two B SaaS companies. And of course, B. Two B SaaS companies have engineers, right? They have developers that can actually build stuff. So for us, build versus buy comes up a lot because our clientele is a builder type of clientele, right. Either whether you're a small or large company. So now when you're in a product company, the idea is build, buyer, partner, or acquire. Right?
[00:03:00] Speaker A: When you want to.
[00:03:01] Speaker B: When you want to grow your product portfolio and that type of thing. But I guess, so I start to think about buy versus build, build versus buy, in terms of where should the team be spending their time. Is it core? Is what we do core to what they do? Because if it is, they should build it. Right. But if it's not core to what they do, then maybe they should procure that instead. But there's all kinds of scenarios in between that make it interesting. So that, I guess, context wise is how I think about buy versus build.
[00:03:28] Speaker A: It makes sense. Nick, I want to hear your perspective because you're an engineer and now CEO. So you have to balance building versus buying probably a lot compared to most operators because you could actually build things if you wanted to. And you've built multiple companies in the past. So when, when something new comes across, you know, your desk and that, that build versus buy decision pops up, like, how do you, what's the, what's like your gut reaction? And do you have a process for, like, thinking through that?
[00:03:58] Speaker C: Yeah, as a default, it's kind of like it's almost never a good decision to build it yourself when you can buy a solution for the right price. And I think about the fundamentals here. If you go back to first principles and the basics here, companies perform the best when you have high specialization of labor. So to Jay's point, if you've got something that you're already doing and you need to make something that is related to that. Well, yeah, go ahead and do that. A simple analogy here. And I think in software, we tend to overthink what we can build. And you don't always account for the time it takes to go out and scope something out and then task engineers with building it. You're not looking at the engineering time it costs. And then the biggest is to maintain that over time. And it's never going to be as good as a company that has specialized in solving this problem here's a really great example. That's not software. So imagine that you wanted to start a simple business. Let's just say it was a pizza restaurant, and you've got your pizza delivery business, you've got your restaurant, you're doing well, but you start thinking about it. I could really use some new sauce.
I could go out and I could look at the different sauces that are out there in the industry that are being made by people that specialize in making tomato sauce. Or maybe should I just start growing my own tomatoes and then making my own sauce and doing it that way? And then you go out and you do all the research, and you get your garden, and you've got tomatoes and fresh tomatoes, and you're excited. Your customers are like, well, you know, we kind of like the old sauce. Or, you know, your sauce turns out not to be as great as, as what you were already buying, and you're spending a fortune doing that. You know, that sounds absurd when you look at it through that lens, but that's what a lot of software companies do, where you've got this area where you're a specialist in, but then you get creative and just like, oh, well, we could do this ourselves. Yeah, of course. You could do it yourself. Should you do it? And I think the answer's often no.
[00:05:52] Speaker A: There's a guy on TikTok that went viral recently, that he lives on a farm and raises his own chickens, and he decided to rebuild the chick fil a sandwich from scratch, like across the board, make it fully organic and do it all himself. And he documented all the steps and showed the finished product, and all the comments were just like, people showing pictures of their own chick fil a sandwich that they paid $3 for, which I think is kind of a good illustration of that.
[00:06:19] Speaker C: That's exactly right. And, you know, I think a lot of times where organizations run astray is it's like, for engineers and product people, sometimes it's fun. Like, it's fun to look out and say, oh, we could build that. We could do our own version of that. But that idealistic view doesn't really materializes in a way that is accretive to the organization.
[00:06:39] Speaker A: So Jay and I have an internal joke on these podcasts where we ring a bell or something when AI first gets mentioned, because it's just kind of inevitable. And all these topics that comes up, I've heard some thought leaders in the SaaS space that, and this is, I think their argument is more specific to vertical SaaS and maybe even more towards enterprise. But they're arguing that AI is making it so easy to build things that, especially in a vertical SaaS market where it's really defined logic and use cases are somewhat finite, that AI will soon be able to let these companies build more internally and build more faster. I'm interested to hear both of y'all's take on that, because part of me is excited about that. Maybe I'm the, you know, the optimist slash technologist that thinks anything can happen, but also, listening to what you all just both said, I could see the same can of worms being opened up. So what do you guys, do you think as far as like today, where we are technology wise, do we think this is going to change? Are things changing?
What are your hot takes on that?
[00:07:40] Speaker B: I mean, absolutely, yeah. I mean, there's a huge difference. Like there's just for people that are listening. One of the things that Baird and I are looking at right now is leveraging a company that was born on top of AI to do sort of our outbound prospecting motion. And we're not going to tell you who it is because we're not giving away that special sauce. We think it's going to be pretty awesome. But like, there's already a marked difference between companies that, you know, remember there were in the old days, it was like companies that were born in the cloud and the companies that were not. Now it's like companies that were born AI versus companies that were born in the cloud.
It's totally different. The way the speed and agility with which you can build and launch new things, it's mind blowing. But for our customers and Nick, I love that your example was on sauce, because I was thinking the whole time you were talking special sauce, it's really, what were you founded to do? Because when you're starting a new company, or even when you're trying to grow an established company, you're looking for a differentiator, you're looking for something that's different than everybody, that you're competing with that special sauce. Right. And so you have to be really, you have to be really conscious of all the things that engineering is the most precious resource in a software company, because everything that they produce generates somewhere between 65 and 85% gross margins once it's shipped. In theory. Right. There's no other part of the organization that creates that much value for the business. Like once you have a digital product in place, like thats where the value in a recurring revenue software type business comes from. So yeah, I dont know if im answering the question that you posed necessarily directly, Baird, but I do think that the speed and the pace of that innovation gets faster, but then theres going to be some differentiators. So in our case, one of the things that I think we should position to people is its not just about the user interface, its about the way that we handle all the, the backend payment system integrations that go along with that.
It's like an iceberg. You see this, but there's like 75% of it is under the water that we're going to handle. As opposed to if you had to build it yourself, you might not realize that until you got into it.
[00:09:55] Speaker C: Yeah, I agree with you there, Jay and Baron. I guess you were asking in this future where AI is able to do everything, AI can essentially enable this like, you know, build it yourself modality, where it's very easy to do that. And I think, you know, there are these trends that come and go. You guys remember the no code movement, which was like super hot five years ago?
Everybody talked about no code. I even think it's in our marketing collateral somewhere. We talked about our no code builder, but everybody was like, man, this is so disruptive. Like we're going to go out, you've got all these tools, bubble code, you know, I can, I don't need to know how to code. We could just build it out ourselves internally, these little internal apps and things like that. If you followed some of those discussions and what would happen is you would build something themselves internally with the no code builder, and then you're going to hit limitations that you don't think of. You're not able to see behind corners. When you start in on a project like this, compared to somebody that specialized in solving that pain point already, who's already, their job is solely focused on solving that. So when you find this tool or the shortcut that allows you to unlock some of that, well, you're still not going to be thinking of all the different areas and you're going to be using something that is not solely focused on solving that in the best way. And maybe a decade from now, this is a very different conversation, but I don't imagine seeing much. I mean, we'll see some significant improvements within AI enabled tools and code, but it's going to be a 60% solution where then you're left with engineers having to pick up the slack from this half finished result.
[00:11:30] Speaker A: Yeah, I've been trying to think through like what are the arguments for building versus buying? Because I think all of us pretty much fall in the camp that generally, you know, unless it's like you said, Jay, specific to your very unique differentiator from other competitors in your offering that you should generally buy. But Nick, I think that makes a lot of sense for when you should build is if you can use these tools to generate quick internal MVP's without having to sell, without having to sign long term contracts with providers, that maybe that is a good place to start. But you have to watch out for the rabbit hole of then spending six to eight months supporting some new MVP and iterating on it, and all of a sudden you've got a second product that your customers weren't even asking for. But it does seem like there is some good fit for building internally. In that case, I think it's also.
[00:12:17] Speaker B: A question of what do you sell? Do you sell software or do you sell domain expertise packaged up as software?
Right. And I think, I mean, obviously we have a vested interest in people buying from us and not trying to build what we, what we sell. But there's a good reason for that, because over the past four years, you know, the founders of this company, and, you know, over the past six months, I'm starting to learn it, too. And other people who are engineers here have really delved in deep. But like, that's why you go to a SaaS company. It's really a. I call SaaS companies customer success engines because they are all about the outcome. They really think through the problem at a deep level. They get to see it hundreds and hundreds of times. So that, to me, is one of the ways that we could overcome the objection is by saying, yeah, of course you can go build that.
[00:13:03] Speaker A: Right.
[00:13:04] Speaker B: And we'll even give you some of the best practices that we've learned over time. But given everything we've learned and everything we've codified into the software based on the domain expertise that we've been able to gather over four years, like, there's no way you're going to replicate that, right?
[00:13:19] Speaker A: Yeah, and that's a good lead in, too. I do want to talk about what we're hearing on the sales front with our customers, because this, I think it's halfway a product of us continuing to move up market as a company. But also, even with our smaller customers, SMBs that we've been serving, build versus buy keeps coming up. Our sales reps have been, part of this conversation was prompted because our sales reps are saying, hey, we need collateral for build versus buy. And this is the first step in that to talk it out. So can you all share, just both of you, what you all are hearing from our customers right now when it's coming up. For those that don't know, Turnkey is a retention automation platform. We sell personalized cancellation flows, failed payment recovery reactivations, a lot of different ways to save customers and reduce churn. And we're starting to hear customers want to build this themselves. What are you all hearing on the front lines from companies in regards to.
[00:14:09] Speaker B: Nick, let me pose a question to you first. Have you talked with specific types of companies that are more pro to want to build versus those who aren't? I have a couple examples. I'm curious what you've seen. You too, Baird. You've done enough selling here to know.
[00:14:24] Speaker C: It'S most common when engineers are running point on key business decisions. Or we have a founder or a executive who is very technology focused, and they may not be as focused on bottom line numbers or resource allocation or that sort of thing.
Sometimes it seems like it's more of an emotional gut type of reaction than somebody that's run the numbers and actually thought about it from a business point of view. Like, if you look at, like, turnkey, let's take, for instance, turnkey, and I'll just give you a very simple example of how I would think about it if I were a company. And you're looking at, all right, well, I want to build out just a basic version of turnkey. Not everything. Let's get an 80% solution in place. Well, what are you going to spend to build that out? Well, it's going to be two engineers. What's the average going rate for an engineer right now? A good one. About $150,000 a year, fully loaded, probably more. And how many engineers are you going to need to put on this project? Might get by with one. It's going to take forever, or you're most likely going to have to throw two engineers at it, and then you're going to have your own hosting costs, you're going to have your own maintenance. After you build this thing, it's going to take months to build it. And by the time you've done that, after three to six months of build time and blow and testing and everything that goes into that, you're going to have this, like, 50% to 80% solution, and you'll have spent about $100,000 or more in your own resources to get it done, which is, you know, it's still like that 50% to 80% solution, and you've got these recurring costs that are associated with that, and it's still not that best solution. It's the great pizza sauce example where somebody is like, it's a passion project. Yeah, I want to have my own sauce. I want to make my own sauce. It's fun to do it, but then your tomatoes, they get an infestation. You got to start all over again. There's some kind of issue that happens. They always do. And the other thing, too, is when I see organizations opt for building instead of buying, there's usually a very rosy lens that they're looking at that decision with, where they're not accounting for the reality, where it's like, my estimates are always right. It's going to take this short amount of time, and you've got to pad that. You got to double the time that an engineer says something. Even as a former CTO and engineer, I'm always wrong on how quickly I think I can do something because all those different factors. So you basically look at that estimate and you double it, and then that's the actual value that you're going to spend in terms of time and money.
[00:16:49] Speaker B: I don't know what you're talking about. I've never seen a wrong estimate from an engineer, or myself, for that matter.
But no. And to build on that, too, think about, there's the direct cost of building, but then there's the opportunity cost. So again, if it's not part of your differentiator as a company, then you've missed $100,000 worth of opportunity to go create new value for your customers as well. Right?
[00:17:11] Speaker C: Dude, that is right on point.
[00:17:13] Speaker B: And then it's prioritization. Like, if you want to change it and iterate it, you find something's not great about what you built in the first place, then you got to go back through the product prioritization process again and wait the engineers to become available to go update and edit that piece of functionality. So, I mean, it's fraught with all kinds of hidden, hidden costs as well.
[00:17:36] Speaker A: I think our cancel flows product is a great example of when build versus buy can go wrong. Because on the surface, a cancellation flow for your subscribers, it seems very simple. It's a very simple form that pops up. We'll do a survey, we'll offer a discount, and we'll start saving customers. And that's not a false statement, but what our customers realize. It seems after about five, six months of that, they start realizing all of the other things that they would like to do, like having dynamic offers. Maybe we need different flows for different types of customers. Well, how do we know what's working at that point? Now we need reporting, we need dashboarding. And now all of a sudden, six months later, they're looking back and they've got this huge product on their hands when they could have just bought something that has all that built in. But it's almost like the second order. Consequences that were missed or upfront because the original assumption was true. It was the second order of that decision that becomes a problem.
[00:18:31] Speaker C: If building that is not already your area of expertise, you're not going to know the right questions to ask or the right things to build.
It goes back to the heart of why we built turnkey in the first place. As a separate business, we were running wave together. We met with business brokers, we were looking at selling it, and we had a massive churn problem. So what did we do? Well, we looked at the market to see what was out there. We hired a churn consultant. We did all these different things. There was nothing out there that did what we wanted to happen to resolve our churn situation. So we spent a long time, I was almost all wholly focused on churn reduction strategies and building that into our product for a good six months to nine months. This was a very prototypical v one version of Turnkey. When that sale finalized and went through and we'd solve churn, it was like other companies need this because this was such a pain point that was outside of our area of expertise. And Jay, to your point about opportunity costs, I should have been spending my time improving the product we already had and doing what we were already doing. Well, just doubling down in key areas. But it took me away from key feature development to something that wasn't an area of expertise. Now, we developed the expertise through doing that, but it wasn't really until we formed our own company that was focused on this, that we really developed that expertise. Because it's not just this one dimensional view you have of your company. You can understand the problem space with much greater context by working with hundreds of companies.
[00:19:57] Speaker B: Well, for the record, I'm glad you did it, but, okay, here's the scenario that I've run into in an actual sales call with a customer that I think is sort of legitimate, and you guys tell me if you agree. So I was talking to a company that creates developer tools and their whole ethos, like, they have handcrafted every portion of this product from top to bottom, from every single button on the page, all the way down to the back end. It's all vertically integrated. So think about like it's the Apple iPhone of development tools. And that's what they pride themselves on to the extent that they don't even, they don't allow any third party cookies. Like they're very security and privacy, you know, oriented and conscious of it. And so they said, look, like, appreciate the discussion, love what you've built. It's just not going to work here because our culture just does not allow this. Right. And so I look at that and I respect that tremendously. Right. I mean, if you have that much pride in your product, every bit of your product, then, you know, absolutely, like, go ahead and build it and you should have pride in your product. And our product should be good enough that we allow you to customize and configure our product to feel like the highest quality parts of your product as well. But I guess I'm curious, like do you guys agree in that situation that sort of like that deep vertical, top to bottom integration of, you know, if you want to handcraft every part of the customer end user experience that maybe that is the right decision and that's okay?
[00:21:29] Speaker A: Yeah, I think so. It's, yeah, it's hard not to respect that if that's how somebody wants to run their business. I love getting suggestion from other people of, you know, what to alter in my businesses, but if I hate when somebody tries to tell me how I should change like the fundamental cores of how I run my business.
So, yeah, I think I totally respect that. And I think what's hard to see, maybe from an outsider's perspective is what are the results of having that culture internally.
Maybe they want to foster a culture of innovation and building ancillary products that they can go sell like we did with our previous business before we built kind of the early versions of Cherokee. So I think there's advantages of that. And as long as you're okay dealing with, like we've said, what comes with building internally and you kind of build that into your operating costs, then yeah, it's hard to. Hard to argue. What do you think, Nick?
[00:22:21] Speaker C: I would argue with it.
[00:22:23] Speaker B: Well, I mean, that's our job to argue with it.
[00:22:26] Speaker C: I can respect anybody that's your value and I can be respectful of value. I just think it's a bad business decision. I mean, I don't see any way around that because you're not specializing. Your focus, to the extent that there's overlap in a tool you're about to buy and one that you've already got, then sure. You know, like stripe for instance. Everybody has heard of stripe. It'd be weird for stripe to go use braintree or Paypal for their internal payments. They're going to dog food and use their own, right? Or for reporting and things like that. I would assume they're using their in house tools and build their own systems rather than go and buy something else. But for most business cases, when you're looking at tools, there's going to be a lot of value that you're not even able to appreciate if you were trying to build it yourself versus buy it. You're also not doing the like, time to cost parity calculation where you look at how long is it going to take to get to the market. And then what's turnkey is a great example because let's say you're going to spend six months to build this out yourself. Well, turnkey in some cases could have saved you half a million dollars in that six month period. So. All right, well, now you're behind even more because there's all this foregone revenue you've missed out on by just delay. So I think there are a lot of problems with that argument. I respect values. I think that's unique. I just don't think it's a good business decision.
[00:23:44] Speaker B: You got me feeling like I should have pushed harder on this guy.
[00:23:48] Speaker C: Well, you know, I mean, we're all like nice, friendly people and sometimes it depends on who you're speaking to. I think occasionally it'll fall on deaf ears if somebody isn't wired to think that way in financial terms and resource allocation, if they're dogmatic and that's their value and they're sticking to it, then even the most compelling business justification in the world isn't going to persuade them otherwise.
[00:24:12] Speaker A: Like we've talked about their sales team, sometimes getting to a no quick is a good thing. Just get to the know and move on.
[00:24:18] Speaker C: That's a great.
[00:24:18] Speaker A: So I'm sure there's other people listening.
[00:24:21] Speaker B: Maybe.
[00:24:21] Speaker A: Maybe they're listening to us and arguing, you know, for building in some scenarios. Can you think of any other scenarios where it does make sense to build? One of those is, I was thinking, Nick, with your point, a really obvious one is when nothing exists. Like when we built, when we were working at wave, we wanted cancellation posts and it didn't exist. So we kind of had to build it internally. And luckily for us, it became a separate product and company. But that's not a playbook that always works. But are there any other scenarios where building could make sense for those that would argue for it?
[00:24:54] Speaker C: I think. Yeah, maybe like you were saying, if the existing solutions are missing some key criteria, you have something you have to have. There's nothing on the market that does it. And then the time it would take to build that thing and build it the way you want it isn't exorbitant. I think that's a good justification for doing it. Jay, can you think of any?
[00:25:16] Speaker B: I already threw out my one.
[00:25:19] Speaker C: Do you guys know? I was just talking to Scott about this. This week, Haiti. He missed this call. I could have called him out a little bit on it. We're working on these different calculators for turnkey and different things. Build versus buy. Like a build versus buy calculator would be a great example, but other ones, like calculating churn, calculating your revenue ceiling. There are a lot of valuable tools that we're looking at building calculators for, because we commonly get these questions from customers. And the solution we were using just to move fast was an existing solution, but it has that company's logo on it, and we don't have as much quality and creative control over the exact look and feel of these calculators. And we were talking about, well, we need to build our own. I was like, man, well, that's a lot of work to maintain it, to loop in engineers and figure out, well, if we wanted to look a certain way, what is the value of that? I doubt our customers and viewers who are using the calculators really care that much about the logo. I don't know that it's hurting us. So the way I look at it may be a little too cold and analytical and detached from the brand, but I have trouble even with something like that, justifying, you know, which. That's a pretty. It's an easier build than dedicated tool. It's just a calculator. But if you're adding a bunch of them, it's like, oh, let's just find a tool, and at some point we can fix it if we want to, but let's just keep moving.
[00:26:34] Speaker B: Yeah, that's your whole engineering is marketing thing, right, Baird. Or engineered solution.
[00:26:40] Speaker C: So.
[00:26:40] Speaker B: But even there, like, that's the perfect case for no code solutions, right, where you can build something out. And by the way, there's a thousand of these things on the market. So whatever we're looking at that had a logo on it, there's probably another one, or there's probably a paid tier that we could have gotten into that we get to take the logo off. Right?
[00:26:56] Speaker C: I think you're exactly right. Yeah.
[00:26:58] Speaker B: So I completely agree with you on that kind of thing. You know, it strikes me that the ownership structure of a company sort of determines how you get to think about these kind of problems, too, in terms of buy versus build.
Have you guys ever heard of the principal agent problem? You heard of this before?
[00:27:17] Speaker C: Yeah.
[00:27:17] Speaker B: So the principal agent problem is like, the way to illustrate this is by asking you a very simple question. Have you ever washed a rental car before you returned it? No, you have not. I'll tell you that right now. Nobody ever has. Right. I have another joke about rental cars.
[00:27:30] Speaker A: I'm shaking my head on mute over here.
[00:27:32] Speaker B: No, but I mean, the idea is that we don't value what we don't own, and if there are teams that are not aligned with some kind of ownership in their company and they're thinking through solutions, they're going to do things that serve themselves. So, yeah, it might be a really fun, interesting problem for me to go build that solution, whatever it is, cancel flows or anything else, but is that really what's best for the company? I guarantee if it was my money, it's also called the somebody else's money problem. If it was my money that was being spent on it and I had to go, then choose.
[00:28:05] Speaker A: So maybe.
[00:28:07] Speaker B: I'm sure Scott will listen. We can push him on it.
If you had to spend your money on it, would you do it? It is his money because he's an owner of the business, too. But it's a really interesting set of problems. So the further people get away from the true ownership in the business, not just the problem that they're solving, but the full business, the outcome, then, I think the easier it is for them to recommend doing things that are interesting for them to do, but maybe not super helpful from a business standpoint. Back to your point, Nick.
[00:28:37] Speaker A: Yeah. Maybe this is too simple of a bow to wrap on everything, but just thinking about the customers that we talk to or the prospects that kind of decide that they want to build, and then thinking about what Nick has been saying is, if you're not thinking about your resources as finite, it's easy to, like you said, like, oh, this is not my money. I can, let's just do it this way, as opposed to looking at the resources and making that calculated decision of what's, you know, what's worth the effort kind of helps determine which way you should go on that.
[00:29:09] Speaker B: Yeah. Well, this is good. So what do you think, Bear? Do we have enough to build out our objection handling list for this one?
[00:29:15] Speaker A: I think so, yeah. This is. We're 30 minutes in, so we'll wrap up. I think this is plenty to help support the sales team. Get a landing page out to walk through kind of all the different angles here. I think this was good. And we can use this to send existing customers or prospects to to help them think through what they should or shouldn't be doing when it comes to build versus buy. Any parting thoughts before we go?
[00:29:37] Speaker C: I knew this was going out to prospects. That would have been a little easier maybe.
[00:29:43] Speaker B: Yeah. Appreciate your authenticity.
[00:29:45] Speaker A: We'll test it in. That's right, low volume rate. We'll test it and see how it goes.
[00:29:52] Speaker C: Nice.
[00:29:52] Speaker B: Do we have a way for people to contact us back, like inbound from listening to this? Because if so, it'd be great to get. If anybody has thoughts or opinions on this, we'd love to hear that feed.
[00:30:03] Speaker A: The best way to track us down and what we'll do is we'll put a big post on LinkedIn that summarizes all this and adds any resources that we've talked about that we can share. But I think the best place is to track us down on LinkedIn. We're the only turnkey can find our company page. Find us there and find us. Of course you can come to our website and contact us, but I think LinkedIn is probably the best place for us to kind of put all this, put all these resources together and let people comment, message back dm us however they want to reach out. Totally awesome.
[00:30:32] Speaker C: So it's fun, guys. Thanks.
[00:30:33] Speaker A: Thanks, guys.
[00:30:34] Speaker C: See y'all.
