Buy vs. Build — The Defining Question for Your GTM Stack

AI coding has upended GTM software: for the first time you can build applications without an engineering team. But building a single-player tool and maintaining a GTM infrastructure are different sports — and most companies are discovering that the hard way.

We have written this to give CEO/CROs a framework to guide their GTM tech roadmap — in partnership with their RevOps teams. Large enterprises have formalized this — 62% have a framework. Everyone else is running on informal process or nothing at all.

AI GTM Transformation isn't a RevOps decision. It's landing on your desk whether you want it or not.

“Every go-to-market leader is being pushed by their CEO, who is in turn being pushed by their board, to figure out how to hit ambitious revenue goals with much fewer resources.”

“AI is more than just the ability to build a custom tool or agent or count token usage. To truly recognize the impact of AI in GTM as engineering and support have done, you need to approach it as a larger transformation initiative.”

Functions with simple recursive loops like coding and customer support have been quickly automated with AI:

• Software: 60%+ of code is written with AI, up from 20% just over a year ago.
• Support: Companies are now resolving 76%+ of support tickets with AI, delivering better experiences faster and cheaper.

There are early signs that these returns are achievable in GTM as well:

“The easiest question to ask is: you closed 25 opps last quarter — what would it actually take for you to close 50? And then the rep lists 10 things that make it so they couldn't. And then you tackle all of those one by one with bespoke agents.”

To get the returns from building with AI in GTM, you can't just vibecode a new tool, you can't bolt on AI to your current foundation. You will need to redesign your entire GTM organization:

• Your data infrastructure: AI without great data doesn't work
• Your data signals: You need to have the data to prioritize your efforts
• The way your organization learns: You need your AI to be constantly learning and improving
• Your GTM functions: You can't just bolt AI on to the same processes and roles

“To really set up that culture of an AI-powered company, you do need it to be top down — right from the CEO, the CRO.”

In just two years, GTM teams have shifted from buying most tools to considering build as a viable option. The smaller you are, the more you lean build. The bigger you are, the more you lean buy — and the more likely you are to have a framework.

This rapid shift has been driven by four factors: fiscal discipline from CFOs cutting tool budgets, ease of building with tools like Claude Code, security hesitancy around unproven vendors, and the low cost of tokens encouraging experimentation.

This shows up in the stats. Many companies are postponing at least some software decisions to consider building internally.

But just because you can build doesn't mean you should. There are costs of building that companies don't consider.

“Six months later, a RevOps leader is going to say: hey, I built 17 different tools over the last six months. I'm having a hard time keeping track of all of them, and they're all breaking, and my board's pissed.”

“When we come up against someone who says 'we're thinking about building this internally,' I say: great. Here are 17 problems you'll have to solve. I literally send them a sheet of the problems. Most of the time they haven't thought about them.”

“They build it, put it in place, announce it to the group and everyone loves it. And then two weeks later it goes down. They have no freaking clue how to fix it. One data feed broke, and all of a sudden it's unusable.”

Companies have been making buy vs. build decisions for years with their software engineering teams. There are many classes of tools that engineering organizations have chosen to buy because they aren't core to their business.

“A year ago we said, you know what, we're going to build a lot of the stuff we think we can get with Clay. But there was only so much capacity we had with our two go-to-market engineers. The opportunity cost of not buying something where the solution already exists is what caused us to eventually shift from build to buy.”

So… how do you pick which tools to buy vs. build? Start with one question:

“Is this business-critical? If yes, that alone should push toward buy-or-partner before you even run the edge/time/context test, given the maintenance/risk/IP burden of build.”

If not, pressure test the buy by asking three questions:

• Can you buy the edge?: Does using the same tool everyone else does work? Or do you see an opportunity to customize for a competitive advantage?
• Can you buy it in time?: Procurement can eat six months. Compare that honestly against the build timeline.
• Can you own the intelligence?: Does the vendor lock you in, or can you leverage the data across your stack?

We see this play out in the data with companies choosing to buy core infrastructure and build the intelligence on top of it.

“Buy your infrastructure, build your intelligence — and where the intelligence itself is core enough to matter but too costly to build alone, co-innovate: let a partner own the rails while you own the judgment.”

“A lot of companies nowadays are trying to skip over that investment (time and people) to jump straight to the AI innovation and it's failing (and costly in time and money) because they've missed the foundation.”

Regardless of whether you decide to buy or build, there are some foundations you need in place to succeed:

“If you give bad data to AI, it just weaponizes it.”

• Intelligence / Context Layer: Many people try to plug AI right into systems of record. But without the context layer, the AI will hallucinate and fail to improve.
• Dedicated Capacity: Separate RTB (Run-the-Business) work from CTB (Change-the-Business) transformation. Without this separation, the urgent always beats the important.
• Budget Flexibility: You don't need much additional spend but you need the ability to add and remove new tools quickly.
• Investment: Over-invest in your AI GTM transformation effort short-term. If you cut before you've transformed, you kill the possibility of success.
• Enablement: Rep adoption is a bottleneck. You can only drive change as fast as reps can learn.
• GTM Leadership Alignment: Your transformation team needs to quickly drive change within the business across all functions.
• Executive support: Pick one C-suite sponsor who can ensure decisions are made fast with a clear mandate.

“The enablement is the thing that people just forget. We would roll out something, pat ourselves on the back — look at this tool we built — and then no one would use it. Not because they don't want to, but if you open up their Tuesday, they have 12 external calls.”

“There's always this push and pull between: do I build the system to help me in the long term, or do I do the hundreds of tasks I need to do today? It's really hard unless you feel both the freedom and the encouragement from your org.”

In most companies, there is no single owner across systems, rep productivity, data, and agents. This means accountability for change is lacking and initiatives slip. We suggest you empower RevOps to drive this change.

AI Agents sit at a current ownership crossroads — shared (and sometimes contested) between RevOps, IT, and Product. Actionable moves to clarify accountability:

• Do not split GTM engineering and RevOps: Both are charged with using data, systems, and AI to drive productivity. Splitting them creates redundancy and confusion.
• Do not split GTM systems and RevOps: If you want to move fast on GTM systems, bring them together underneath RevOps.
• Ensure RevOps is an equal customer of your data team: For GTM AI transformation to work, RevOps needs equal call on data resources.
• Support them with a central applied AI team: This team equips RevOps with AI infrastructure and cross-functional foundations — it doesn't own GTM systems.

“One of the Clay tables Canva runs monitors the social accounts of all their major customers looking for poor graphic design. The problem is one or two reps were doing that. Canva has hundreds of reps who could be. Taking that little nugget and deploying it on behalf of the entire organization — that's GTM engineering at its best.”

“What an Applied AI engineer builds isn't 50% better, it's usually 500% better.”

“Encourage experimentation to build a V1 prototype — then go to RevOps, let's put this into production.”

If you can't measure ROI, you shouldn't invest in it. Yet, many companies struggle to measure the impact of their AI GTM investment.

• Productivity (Revenue per Head): Easier to measure as you already track these as core financial metrics and have benchmarks.
• Outcomes (Win Rate): Harder to measure because many factors influence them and they won't typically move as dramatically as productivity metrics.