Podcast
September 23, 2026
Episode 109: Build the Workflow, Buy the Risk
Brandon Smith of QuotaPath breaks down the build vs. buy decision for RevOps teams — including when AI-built tools make sense and when to pay the vendor.
Most RevOps teams have never had a shortage of ideas. The bottleneck has always been execution — specifically, the inability to turn an internal pain point into working software without a developer, a budget approval, and a six-week sprint cycle. AI has changed that calculus in a meaningful way. And with it has come a question the RevOps community is only beginning to wrestle with seriously: just because you can build it, should you?
Matthew Volm sits down with Brandon Smith, Director of Revenue Operations and AI Operations at QuotaPath, to work through that question from first principles. Brandon brings an unusual vantage point: eight years in RevOps, seven of those at a single company, and a front-row seat to both sides of the build-versus-buy equation — as a practitioner who has replaced expensive vendor tools with internally built alternatives, and as a member of a team whose product (commission and compensation software) is exactly the kind of thing operators sometimes convince themselves they can vibe-code their way around.
The shift in the build-versus-buy conversation didn't happen because RevOps operators suddenly became better at identifying problems. It happened because the execution barrier collapsed.
"For RevOps folks, the bottleneck has never been ideas. We have a lot of ideas. We know the systems. The bottleneck has been us being able to write production-ready code. I'm not a developer. I don't write Apex code. I don't write any sort of code. And so with the introduction of AI and actually being able to write code at scale and not have to actually know really what's going on behind the scenes... has really allowed us to actually build things rather than just have these ideas." — Brandon Smith
This is the entry point to the conversation, and it's worth sitting with. The constraint wasn't creativity or technical knowledge of systems — RevOps operators have both. The constraint was the last mile: turning a clear mental model of what a workflow should do into something that actually runs. AI has, in a material way, removed that barrier.
The implication isn't that every RevOps team should immediately start building custom tooling. It's that the decision criteria for build versus buy has fundamentally changed. A tool that would have required dedicated engineering resources two years ago can now be prototyped by a RevOps practitioner in an afternoon. That changes the math on cost, on timelines, and on the risk calculus around whether buying a vendor solution is actually the more efficient path. For more on how AI is reshaping what RevOps teams can realistically take on, Episode 97: Everybody Has AI. Nobody Owns It. covers the governance questions that follow from exactly this moment.
Brandon's most concrete example is a customer success and account management platform that QuotaPath had been paying for at roughly $50,000 per year. The decision to explore replacing it wasn't driven by cost alone — it was driven by a signal that most operators recognize but don't always act on: low adoption.
"There was limited adoption across the team... and so that was the first area of, okay, do we actually need a tool like this, or do we need to just build something for ourselves that does some of the things that this tool does? And what we ended up finding is that these signals weren't really tool specific. There was nothing that they were telling us that we couldn't find in our own datasets on our own. And that's going to be the most critical component — because if there's nothing specific to that tool, like a specific benefit to that tool that brings, then it's probably somewhat easy to then replicate." — Brandon Smith
This is the diagnostic logic worth internalizing. Low adoption is a symptom, not a conclusion. The question beneath it is: what specific value does this vendor provide that we couldn't recreate from our own data? If the answer is "not much," the calculus shifts. If the answer is "quite a lot — and the value is proprietary to their platform," then low adoption is probably a training or change management problem, not a build opportunity.
Brandon is direct that replacement doesn't mean zero cost. There's maintenance, token costs for AI-generated insights, and the overhead of managing feature requests from internal users. "It's not gonna be 50k a year. It's going to be maybe thousands a year." That's a real reduction — but only if the team accounts for the full cost of ownership, not just the initial build. Fixing the Tech Bloat Problem Without Making Enemies covers the broader discipline of rationalizing a tech stack before adding or replacing anything.
The most practically useful framework Brandon offers is also the simplest: the "blast radius" test.
"The blast radius of the error is minimal at that point. Whereas the blast radius of an error to a commission check is about as bad as you could potentially have in a RevOps seat." — Brandon Smith
The example he uses to illustrate low blast radius: a weekly Slack digest that goes out as part of a new go-to-market motion, summarizing signals and offering suggestions on how reps can improve their pitch. If that digest fails to send, someone notices, Brandon gets a message, and the issue gets resolved. No rep loses money. No deal falls through. The blast radius is small.
Commissions are the opposite end of the spectrum. Get it wrong in either direction and you've either made finance angry (overpayment) or made sales angry (underpayment). Brandon's framing is characteristically pointed: "Commissions is the most thankless job at a company. If you get it right, great. If you get it wrong on overpayments, finance is mad at you. If you get it wrong on underpayment, sales is mad at you. It's the most thankless job that nobody comes to you and says, 'Thank you for running my commissions this month.'"
The practical rule that follows: anything touching someone's livelihood — their paycheck, their job security, their compliance record — is not a candidate for an internally built replacement. The question to ask isn't "can I build this?" It's "what happens when this breaks at 8am on a Monday and a rep is trying to understand why their check looks wrong?" If the answer involves real financial or personal consequences, buy the vendor solution designed to handle that risk. For a deeper look at the complexity that makes commission tooling genuinely hard to replicate, Episode 60: Pay Day Problems: Comp Plan Lessons Learned is worth revisiting.
Brandon's examples of things worth building internally share a common profile: they connect existing systems, surface insights that weren't previously visible, and operate in a context where a failure is recoverable.
One example is a scorecard coaching system — "Gong-esque, but with a specific wrapper tied to our go-to-market motion." Reps can see how they've performed in the current month compared to prior months and how they stack up against their team. If it breaks, someone Slacks Brandon, he has a conversation with Claude Code, and it gets fixed. The blast radius is minimal. The specificity to QuotaPath's particular motion is what makes it worth building rather than buying a generic solution.
Another example is the handoff workflow. QuotaPath had problems with knowledge drop-off during transitions from sales to post-sales. The solution: a mixture of Claude and Dust to generate handoff notes that are rich but digestible for each stakeholder role.
"Start with a problem and then come up with a solution to that problem. If the problem is rooted in a tool that you have, then go figure out how to solve that problem with that tool. If you can build it yourself, then by all means go and do it, or bubble it up with the vendor and see if it's on their product roadmap." — Brandon Smith
The through-line across every example Brandon cites is that the build decision starts with a real problem someone is experiencing, not with a technology looking for an application. This is the discipline that separates useful internal tooling from the sprawl problem he explicitly warns against — six different tools that reps have to visit across six different tabs to complete their day. Perfecting Team Handoffs explores the process side of the same challenge Brandon's tooling is trying to solve. Scale Faster With a Healthier Marketing-to-Sales Handoff adds practical context on how to identify where handoff breakdowns are actually costing revenue.
Brandon's most recent purchase — two months before this conversation — was a data vendor providing buyer intent signals based on social data, with integrations into outbound systems across email, LinkedIn, and calls. The decision logic was different from the build cases.
"That was more of a this vendor solves a problem that could potentially give us a competitive edge. Let's go use this vendor." — Brandon Smith
The distinction is worth naming. The CS platform they replaced didn't offer anything they couldn't surface from their own data. The intent data vendor provides signal that isn't available internally — it's proprietary to the vendor's data network. Building a replacement isn't a viable option, because the value is in the data itself, not the workflow around it.
Brandon's purchasing approach has also shifted in response to how quickly the landscape is moving. QuotaPath has been a Clay customer for three years and remains on a month-to-month plan. The reasoning is straightforward: when new capabilities are emerging fast enough that the tool you buy today might be meaningfully superseded in six months, locking into an annual contract carries its own risk. He recommends doing tech stack reviews more frequently than the traditional annual cadence — quarterly, in some cases — because the environment no longer holds still long enough for an annual review to stay relevant. Your 2025 RevOps Tech Stack, Simplified offers a useful baseline for thinking through what belongs in the stack at different stages.
The practical question for RevOps practitioners isn't "should I build or buy?" as an abstract preference. It's "where do I start?" Brandon's answer is consistent across both the tool rationalization context and the net-new build context: user interviews first.
"Sit down with a rep or join a Zoom with a rep if you're not in person, and just have the rep describe their day and the pain that they feel in their day. And if you build something for them, that's where you're gonna get usage. If you build something that you think that they're going to want and think that they're going to use, they might not adopt it, and then you'll feel like you wasted time." — Brandon Smith
The listening tour serves multiple purposes. It surfaces the actual problems worth solving, which is different from the problems that seem worth solving from the outside. It also creates adoption pre-conditions — if reps articulate the problem and then a solution appears that directly addresses what they described, adoption is far more likely than if the tool was built on assumptions.
Brandon adds a secondary benefit: listening tours sometimes reveal that the adoption problem isn't a technology gap at all. Maybe a vendor's platform has a feature that solves the problem but hasn't been turned on, or hasn't been communicated to the team. In that case, the right answer is a training session, not a build project. The discipline of starting with listening keeps teams from conflating "we have a problem" with "we need to build something."
The broader principle — start with the problem, not the solution — applies with particular force in an AI environment where the technology is constantly visible and constantly improving. The temptation to build something just because it's now possible to build it is real. The antidote is the same discipline RevOps has always applied to good systems work: understand the underlying need before deploying any tool to address it.
Check out our blog, join our community and subscribe to our YouTube Channel for more insights.
Our average member has more than 5 years of RevOps experience. That means you’ll have real-time access to seasoned professionals. All we ask is that you’re generous with your knowledge in return.
