Build vs Buy: AI Solutions Across Your Sales Org

Alex, co-founder of Grow AI, breaks down when to build AI tools in-house versus buy platforms for sales teams. He walks through a decision framework based on whether capabilities are commodity or differentiated, then shows how unchecked AI experiments create token spend spikes and inconsistent usage. Grow AI handles governance and centralized workflows while letting teams own their differentiating logic.
Chapters
This is a decision that I think just about every organization and revenue organization is going through today, which is what should we be building ourselves in-house and what we should— what should we be buying? This is certainly a decision we go through as a company as well all the time. So I'm going to walk you through a framework that we use ourselves at Grow and then at the end actually share that framework with you too. So a little bit about me. I am the co-founder and co-CEO of Grow AI. I have spent sort of 14 years on just about every, every side of this decision. My career started— I was the first sales hire at 19 at a tech startup, and I had one of those crazy startup journeys where I was the VP of sales at 20 and I had a team of 15. I then went to some big companies like HPE, Then I built a revenue consultancy, worked with hundreds of organizations, and then I co-founded and sold a sales training company as well. And on the personal front, as you can probably tell, not American. I am a British New Zealander. I spent half my life in the UK, half my life in New Zealand and Australia, and now I'm based in San Francisco. And when I am not working, boxing and poker are my 2 2 hobbies that keep me sane and help me deal with stress. Would love if, if you all kind of drop a quick intro of yourself in the chat and maybe share like the hardest thing about being a sales or revenue leader or a revenue professional in 2026. I'd be really curious to see those. So to set the scene a little bit here, Over the last kind of 18-24 months, AI has gone everywhere. Every revenue organization is leveraging AI in some way, shape, or form. But from what I've seen, and I've spoken to a lot of revenue organizations and CROs and VPs of RevOps, is that we don't really have control over a lot of it. You know, we've got maybe Malcolm, my AE, he's doing some cool stuff in ChatGPT. We've got Tanya on my team, she's doing some cool stuff in Claude, but I don't really know what they're doing. I can't see it. I can't— you know, they tell me what they're doing, but I can't actually see it. I have no visibility of that. We've got, you know, skills and prompt docs that are being created that don't really get shared around. We've got personal workflows that leave if that person does. And don't get me wrong, some of this usage is genuinely really good and valuable. The problem is a lot of it isn't shared. Standardized or measured. And I was at an event a few weeks ago in New Orleans with about 100 chief revenue officers of everything from Series B startup to Fortune 50. And everyone's kind of going through and muddling their way through this at the moment. And no one can answer the question of what is all this token spend and AI spend actually doing for our number? What is the ROI of all of this? So if that's you, like, you are not alone. Everyone's going through this right now. We're all struggling, including us. Um, I'd like you for a moment just to imagine— go, go back to that kind of key challenge that you're facing in your organization today, that the hardest thing for you. Let's just imagine for a moment that 6 months ago your team approved a $100K build to close that gap. So you've approved a $100,000 budget to go and build some internal tooling to solve that gap. AI made it really cheap to start. The demo looked easy. The sprint got funded. And then I want you to answer the question, was it the right call to build? Hold that decision, and we're going to come back to that right at the end, because AI really has changed the cost of building. It's basically made coding free. You know, building a prototype, you can, you can do a prototype in a day. The technical barriers to entry are almost completely eliminated. I'm a non-technical person and I'm building stuff in Claude Code. So that time to first demo is really, really fast. But AI did not change the cost of ownership. Governance, a very sexy word, but governance, you know, AI does not eliminate it. QA, security, maintenance, ongoing maintenance, adoption and change management. So actually getting dozens, hundreds, or thousands of people to actually adopt this stuff. Institutional knowledge, and of course token costs at scale. You know, we've probably all seen in the news Companies who have blown their entire AI budget in Q1 or Q2 of the year. We've probably all experienced something ourselves similar to that. I know we certainly have had our fair share of, you know, token cost, you know, spiking. So all of that to say, the easier that building becomes, the more disciplined that we actually have to be around whether we should build or not. Because a build is a product, it's not just a project. The question shouldn't be, can we build this? Because honestly, the answer today is probably, like, probably yes. But the question has to be, who's going to own this, not just today but in year 2? Who's the owner? Who's going to own the roadmap? Who's going to own the business outcomes? Who's going to maintain this? Who's going to run model evaluations week in, week out? To make sure that you're using the right models, the most cost-effective models? Who's gonna handle the integrations when they break? Who's gonna handle bugs? Because like, there will be bugs. Who owns this if the main builder leaves? And then the final point, which I think is often in all the excitement of how easy it has to become to build, often forgotten, which is What other work, what strategic work or other priorities does committing to building this ourselves displace? And, you know, I've seen product and engineering teams diverted from their core product roadmap to start building internal tools. And like sometimes maybe that's the right answer, but it's not always the right answer. So if you cannot name the long-term owner before the first sprint, that's a really good indication you probably shouldn't. Build this in-house. Now, buying certainly has its fair share of problems too, and fair share of costs. You might outsource some complexity, you don't eliminate it though. And there is obviously the raw cost of the licensing, potential implementation costs, salespeople coming at you to sell you premium upsells, seat growth. So that's like the actual dollar cost. Then you've got the hidden P&L, which is integrations, administration of this new tool, enablement and change management, any unused seats. And then there's the strategic costs too. That's your data fragmentation, that's your switching costs and potential vendor dependency. So vendor sprawl is a form of tech debt. It might not show up in your product team's backlog, but, you know, that's got a cost associated with it too. So the framework that we've been using ourselves, and the context here is we've got an incredible engineering team and cracked AI engineers who could build anything and everything that they want to build. Um, and because of that, we actually have a framework in terms of what should we build versus what should we buy. So the first, uh, area is core infrastructure. So that's, that's like a commodity. That's the— and the question to ask yourself there is, does every go-to-market organization need roughly the same capability. So examples, like really simple examples here, CRM, call capture, billing software potentially. You know, these are the sorts of things where the default should typically be just buy it. It doesn't make sense for your team to try and rebuild Salesforce most of the time. The second area is process. So this is your business logic. And the question to ask yourself there is, does this encode how your company operates? Examples of that are your opportunity stages, your routing rules, your approval flows. And typically the default there is to configure or a hybrid of buy and build. And then the final area is your core business intelligence. This is the stuff that's differentiated for you. And the question you want to ask here is, Does getting this right create a unique advantage for our business? And if yes, the default here is to own this yourself. And examples of that are ICP-specific logic, risk signals that make sense for your business, uh, forecasting logic. So the questions to ask either yourself or the enthusiastic person in your team who wants to go build something internally Before the demo or the sprint, ask them these 4 questions. Is this a commodity or is this truly differentiated for us? Commodity leans buy, differentiating leans own. Number 2, does the market solve this well? If mature vendors solve it at your required depth, at least evaluate it before committing to a build. Number 3 is what is the 3-year total cost of ownership? Not year— not just year zero, but what does the total cost of this look like over a 2 or 3 year period? And then the final question is, who owns this long term? Name the product owner before committing to that first sprint. Now we actually have a, um, a tool available for this. Um, someone from my team I think is going to share it in the chat right now. So if you're going through this kind of build versus buy decision, you know, feel free to take advantage of that. We've used like industry benchmarks and so on behind the scenes to build that out, and we use it ourselves for these kinds of decisions too. So back to that $100K kind of hypothetical decision, build decision. Would you decide differently now having gone through this? And I think the answer here really was never build or buy. I think the answer is you buy the platform, but you need to own the logic and the differentiating stuff to you. You need to own that yourself. So if any of this resonated with you, this is how we think about things at Grow. Um, you know, the short version on Grow and who we are, we help sales organizations to run autonomously. Most companies we speak to have their teams running on dozens of different AI experiments, and we turn that fragmentation into one system the whole company runs on so that they can see it, control it, measure it, and ultimately sell more off the back of it. Think of us as a platform layer for go-to-market execution. Your differentiating logic all stays yours. Configured in Grow but owned by you. So if you're interested to learn more about Grow, you can go to grw.ai. Um, and then if you have any questions, drop them in the chat. Uh, happy to answer them here. And then also always happy to talk offline to anyone who's kind of going through this and just wants, wants to, you know, uh, discuss these kinds of things. Um, always happy to speak to revenue leaders. And I should probably actually have a look and see if there are any questions in the chat.
Yes. The question is, how is Grow AI different from what Claude can do?
Great question. Okay. So short answer here. Claude is an incredible horizontal tool, but it is single player in terms of you don't know what, you know, like I was saying at the start, you don't know what Malcolm's doing with his Claude and I don't know what Tanya's doing with hers. Grow is specific for the revenue organization and we add the governance layer and control layer so you can deploy stuff across the whole company, across 100, 1,000 sellers all at once and maintain consistency and reliability at scale.
So when it comes to the decision, build or buy, I've heard so many different answers from so many different people. I'll give you just one example. Michael Wehning, the CEO of Calyx, a $2.5 billion company, 7,000 employees. He says, absolutely not. Our IT department is not competent enough, and I'm not confident enough that they can do what outside companies make it their daily bread and butter. Their lives depend on it, and there are just too many complications. I mean, there, he says there are exceptions, but He is a Salesforce shop and he uses, uses Agentic AI and he is totally for buying and not building.
Yeah. And, you know, I think that's a really good example of even a sophisticated organization with a lot of internal resource. You'd kind of automatically assume that they would be open to building more themselves. But I think they've, they've realized that, yeah, there's people who think about this stuff every single day. Like, you know, if I use our team as an example, our engineering team and everyone in our organization wakes up every day thinking, how can we help sales organizations run more effectively, more efficiently? And, you know, Claude isn't doing that because Claude is trying to solve a broad problem.
Right.
We're trying to solve a much more narrow one. So what does that mean for a customer? It means that You know, when they start on Grow, things start working immediately and there's no long project to get it up and running. You're gonna start seeing like automations and workflows and things just happening on day 1.
So the next question is, what if we all, we already committed to something built in-house? Some parts take forever to build and some parts give mixed results.
I love this question. I've seen this in the wild a number of times. A really good example is we— I won't name the company. They had spent about just over $1 million building out an engineering and ops team to solve company problems internally. We solved their problems for about $100,000. And, you know, at that point, it kind of becomes a business decision of Our revenue team needs these problems solved today. We have a specific outcome in mind, and if it's taking too long, the outcome has to take precedence. And I think everyone got caught up in the excitement of building at the start of the year, but actually, like, what do we care about ultimately as a business? Do we want everyone in our team to become a builder, or do we actually have a number we need to hit at the end of the year? And I think more companies are coming to the latter now of like, actually, we're a business. We have to make the number.
I know that that's an obsession. Emery is asking, what failures have you seen where people have approached using AI in a way that hurt? And did you fix it?
Goodness, lots of times. I think inconsistency is a big one. of having, you know, seeing organizations who are maybe experimenting with, you know, like a lot of, a lot of companies at the start of this year gave everyone in their company a Claude license or a ChatGPT license and said, go experiment. And what that led to from a sales perspective is everyone's selling their own way. There's no consistency. Everyone's emails look different, everyone's sales process looks different, everyone's updating Salesforce differently, etc., etc. How we fix that is you deploy the workflows once at a central layer, and now everyone's runs exactly the same, so that everyone's running on the same playbook at the same time. So instead of having just your top 1% of performance getting the uplift, now you're bringing that middle layer of performance up to the, up to the level of the 1%.
Michael, I see you taking notes furiously, and I know you have a very important question.
Well, I think build versus buy is probably one of the more difficult business decisions right now with the technology accelerating so fast. And you can build something fairly quickly, just like you said, Alex. Me being a non-engineer, I could go build something on Claude Code. It won't be production-oriented. However, at least it'll be a concept. You know, and you raised some good points here about who's going to own it in 2 years. So think about the intelligence that you would acquire from the moment you start into 2 years later. Help us define what you mean by owning the intelligence over that period of time where, hey, we're gonna, we're gonna buy, then we're gonna get experience and value implementing workflows, automations, and systems, processes, and everything that's part of us operating the business. Is that part of the intelligence that you're talking about? Focus on that and let that grow. Yeah.
So, so the way I think— let me answer this question. There's a couple of ways I could answer this, but I know we don't have super long. So what I am a proponent of is what is the core intelligence that is specific to your company? So that's how you sell. That is the specific way that you run things, the specific ICP you sell to and all of the like intelligence you have around that. That makes sense to own. Like, you don't want to outsource that. But the infrastructure layer of, for example, like the plumbing that is gonna automate some of these things and make your team more effective and efficient, does it really make sense for you to build that in-house? And then everyone forgets that a build is not a static thing. You build it on day 1, but on day 14, now you have a sales team and they all have ideas of how it can be better. And then the same is going to keep happening for the throughout the year. So that's what I mean of like you own the things that you're really good at, and then bring in solutions that can be the plumbing kind of underneath that can enable you to go faster.
Yeah.
So when you refer to it as plumbing, that's infrastructure.
Yeah. Yeah, exactly. And like you know, we consider ourselves infrastructure of like agentic infrastructure for the revenue organization. Salesforce's CRM infrastructure, like another key pillar of the if the You know, a revenue organization, etc., etc.
Yeah.
So that requires a different kind of thinking. You know, the— I'm reminded, you know, when I think about the whole of the conversations we had all day, it boils down to one big challenge, which is judgment. And people say that the real danger of AI isn't that machines are starting to think like us. The real danger is that we stop thinking. And, you know, you think about it, that common sense was something that everybody had. And now it's something, it's becoming something that we outsource and then we get mad when it's wrong.
Yeah, totally. And I think like, I think we've already kind of swung back a little bit. I think there was a lot of excitement at the start of the year in particular, and I think we've kind of swung back into outcome thinking, outcome-based thinking again, which, you know, as a business, as a revenue organization, you have to think that way because you don't, you know, It doesn't make sense for every salesperson to suddenly become a product engineer. They've got enough to do. They're already, they're already only spending 30% of their time selling. Now we're giving them more stuff to play with. Like, actually, we need to make sure that they're, instead of spending 30% of their time selling, they're spending 70% of their time selling. Um, so yeah, I think outcome, you got to put the outcome first, uh, and kind of park the excitement of how fun it is to build.
Yeah. And I second that because we need outcome-based thinking because now we have outcome-based pricing.
That's true.
Everything will be performance-based. Alex, I love your journey to get into sales at 19 years old. That's incredible. And VP at 20.
Yeah, it was a crazy one. I dropped out of college. My parents were furious. They forgave me maybe 5 or 6 years later.
Well, thank you also for bringing that charming New Zealand accent to our event.
Thank you for having me. It's been a lot of fun.
Yeah, I wish we could have gone on a lot longer, but we are already 3 minutes in overtime and we have another presentation coming up in 7 minutes. So thank you, Alex. I encourage everyone Go to grow.ai and to complete your growth journey.
Yeah.
Thanks so much.
Thanks, everybody.
See you guys.
More from Gerhard

What Selling Looks Like When Your AI Agents Have the Context Your Sellers Do

Better Conversations, Smarter Support: Wearable AI in Business

When Scarcity-Built Systems Meet Abundance - The Judgment Gap in AI-Powered Sales Leadership







