Shownotes
A lot of operators think the problem is execution when the real problem is unnecessary infrastructure. This episode explores the hidden cost of building custom tools, AI agents, and internal systems before questioning whether they should exist in the first place. Ray breaks down why complexity compounds faster than most businesses can support — and why disciplined simplicity is becoming a competitive advantage.
What You’ll Learn in This Episode
- Why every new internal tool creates long-term maintenance obligations
- The “decision above the decision” most builders skip entirely
- How strong operators solve problems by reducing complexity instead of adding infrastructure
//
Welcome to The Ray J. Green Show, your destination for tips on sales, strategy, and self-mastery from an operator, not a guru.
About Ray:
→ Former Managing Director of National Small & Midsize Business at the U.S. Chamber of Commerce, where he doubled revenue per sale in fundraising, led the first increase in SMB membership, co-built a national Mid-Market sales channel, and more.
→ Former CEO operator for several investor groups where he led turnarounds of recently acquired small businesses.
→ Current founder of MSP Sales Partners, where we currently help IT companies scale sales: www.MSPSalesPartners.com
→ Current Sales & Sales Management Expert in Residence at the world’s largest IT business mastermind.
→ Current Managing Partner of Repeatable Revenue Ventures, where we scale B2B companies we have equity in: www.RayJGreen.com
//
Follow Ray on:
Transcripts
Just because something can be built doesn’t mean that it should be built. And most of the time it shouldn’t. And this is the lesson I I keep having to coach builders on. And to be clear, I love builders like within a business. I work with engineers who are intelligent as fuck. And they can spin up whatever you put in front of them.
The problem is when you can build anything, you tend to want to build everything. And 24 months from now, you you end up drowning in your own infrastructure that that you don’t have the team, the capacity, or the expertise to maintain. And there’s a very clear pattern, and there’s a decision above the decision that most builders are making.
And the decision that they’re making is: how do I build this? Right? The decision above it, the one most operators skip, is: should this even be built at all? And and if it should, what’s the most effective way to do it without adding complexity to the business?
Let me give you two real examples from from my own company. First one is in customer success. So CS comes to us and says, “Hey, we need a dashboard. We need we need visibility into these pieces of data.” And my engineer, because he’s a builder—like that’s his instinct—says, “Alright, cool. Like we we’ve got a database over here, we built it for the SDR management team, or we already have a custom dashboard that we built for the sales managers. Let me just spin up another dashboard for CS.” And and from a builder’s standpoint, that’s the right answer. It’s buildable, it’s not crazy difficult, we already have some of the infrastructure. So alright, cool, makes sense.
But here’s the decision above the decision. CS needs basically six pieces of data. Like when you look at the list of what what they’re asking for, and four of them are already in the CRM. So instead of building a whole new proprietary dashboard—which means we own it, we maintain it, we support the the database, we’re hostage to to that platform that the that we built it on, if that platform goes bust like we’re fucked—like instead of all that, why don’t we just add two fields to the CRM? Right? Like the other four are already there, we build a a native report inside the CRM—which, by the way, they have their own development team massively larger than than ours, and they have way stronger data integrity than the database that we’ve kind of built on our own.
And now CS has a a vested interest in maintaining the CRM hygiene. Because you know when when CS has to get in there and you know use the the CRM for data, now it’s not just a sales problem. CS has a vested interest in going in there and saying, “Hey, we’re seeing duplicates” or “We’re seeing this.” That’s good. We have more people who have a vested interest in the outcome that we all want. And and we and we need that anyway because right now sales is the only person doing that. And and like as all systems go, like it it erodes; the data quality erodes constantly.
So you do it this way—like just build a couple fields into the CRM versus building a new proprietary dashboard that you have to to maintain yourself—you get the same outcome. Like two custom fields versus proprietary dashboard. To me, it’s a no-brainer. Um, now but zoom out. Why is the second option better? Because every time you build something, you own it. You support it, you maintain it, you’re hostage to whatever stack that you built it on, whatever you’re hosting it on. It’s it’s build time that you didn’t have to spend, it’s a knowledge base that that you have to maintain, it’s tech debt that you have to carry. And and you multiply that by every "let’s build it" decision that you make over 24 months and you end up with this infrastructure stack that you you don’t have the team, you don’t have the capacity, you don’t have the expertise to support that if you just go and build everything.
And by the way, the the written version of stuff like this goes out weekly on raizemail.com if you want to sign up, it’s completely free. And every week we send out frameworks, things like that. Okay, second example—and this one’s even better. I tell my inner—I tell the engineer: internal ops execution is is suboptimal. Right? Like I’ve been on this execution kick, I just want I want pristine execution within the business. So I said, you know, execution isn’t isn’t where I want it to be, we see some things that are slipping, can you propose a solution?
And he comes back and he says, “Yep, gotcha. Um, let’s build a simple AI agent that triages all the requests that are coming into the ops team, and that will kick back feedback to the person that’s making requests, which should help triage and and reduce the number of requests that are coming in. It’ll help prioritize things, we can track it, dada dada.” And again, from a builder’s lens, really fits; smart answer. Right?
But play that forward. Now we have to build the agent. Then we have to introduce it to the team. Then we have to train them on it. Then we have to force the behavior change—because they’re not going to use it the first time, and when they do start using it, they’re not going to use it the right way—so there’s a training that has to go on. Then it—because it’s AI—it’s going to give shitty outputs the first 100 times. So we’ve got to train AI. We’ve got to build the knowledge base, we’ve got to maintain that knowledge base. We and we’ve now spent build time that we don’t that we don’t have on a tool we now have to maintain forever to to solve a problem that probably doesn’t need a new tool at all.
So I so I came back and I said, “What if we just look at our existing tools and I make that the constraint. No new tools. Right? How do companies that are running the exact same tech stack solve this problem without building something new, without integrating a third party, without adding more complexity and complication?” And specifically, I asked how how would—how would 37signals solve this execution problem? Because 37signals developed Basecamp. We run Basecamp, they run Basecamp. They’re a—I think a nine-figure company, something like that. And they’re running on the same software we are. They insist on simplicity; like they’re pretty public opinions about how they how they operate. So surely they’ve had to solve this same problem internally. How did they do it? Like did they layer on new stuff? Probably not.
And that one question gave me the answer in about 10 minutes. Because I start, you know, I go into Claude and I start saying, “Hey, smart version of Claude, how would 37signals solve this within Basecamp?” And you know we came back with a with a you know centralized all the tasks and like the request in into a Basecamp project, set like a a really standard cadence for triaging it. You then you’re done. You do a couple of minor changes and you’re done. There’s no build time, there’s no new tool, there’s no new automation, there’s no new like project to maintain. The team didn’t have to change anything, they have to get trained on anything, they didn’t have to change their behavior. In fact, it simplified their lives. And it cut about half of the noise off of our ops list immediately. Same problem, two completely different paths to get there. One adds infrastructure and the other one deletes complexity.
Quick warning on on the building side because this is real. One of my—one of my closest friends is in AI and coding, like genuine fucking genius. Like lives in it every day. Uh, he he vibe codes constantly; he loves it. And the thing he keeps telling me is—by the way, he vibe codes but he’s also a longtime developer. Okay? So like he’s vibe coding; this is not new to him. Building is not new to him. And he keeps telling me: you got to be careful because AI is wrong about 2% of the time and that 2% compounds.
So when you bake it into these proprietary systems that we want to build—let’s build this AI agent or let’s build this new platform or let’s build this new dashboard or let’s dry—like everybody can build something with AI now. And when you do that, you bake in these 2% problems into proprietary systems and you keep building on top of it. And there’s a—there’s a real tech debt problem that accumulates and compounds over time and once you get to a certain point, it’s very difficult to go back and undo all of that. Especially when you’re layering on different tools from different platforms and all over the fucking place. And and it—this is particularly toxic in a in a small business that doesn’t have like a real engineering function to to maintain all this stuff.
So if you want a framework on this, I it’s basically Elon’s algorithm. You know, first: question all the requirements. Second: delete all the steps that you can. Then simplify, then accelerate, then automate. In that order. And and most operators jump ahead. Like let’s question the requirements, let’s delete as much shit as we actually can. And most operators are looking to automate or to build a new tool and they skip these first few steps, which is how you end up with a with a tech stack that’s a museum of of half-finished shit all over the place.
So the takeaway is this: building isn’t the skill. Like it’s a great skill. Deciding what not to build is the skill. If you’re a builder or if you have a builder on your team, this is the conversation to be having. Because the instinct to build is a gift—like you don’t you don’t want to kill that—you you just want to put one decision in front of it: should this be built? And and if yes, can we solve it with what we already what we already have first?
Right? Like play the—play the tape forward 24 months. If you keep saying yes to every new build, every new proprietary platform, every new "let’s customize our own tool," every new "let’s vibe code our own CRM," and "let’s vibe code our own you know ERP"—like you aren’t going to have a business because you don’t—you have an infrastructure problem at that point. And you don’t have the team to support it. So simplicity wins. Hope it helps. Adios.
