How to Think About Build vs. Buy in the AI Era

“Build Your Intelligence. Buy Your Infrastructure." With Kyle Norton.

Jul 07, 2026

If you were forwarded this newsletter, join 9,451 weekly readers—some of the smartest GTM operators & founders—by subscribing here:

Thanks for reading this hand-rolled, 100% organic, farm-to-table (human-written) newsletter.

Presented by:

Clay is the infrastructure GTM engineers build on. Start building for free.

& Supported by:

Attention → AI Agents for RevOps.
Clarify → The Autonomous CRM. Sell more, admin less.
Clearskies → The Context Layer for Revenue AI.
Nooks → All your outbound. One AI workspace.
Rox → Revenue Agents for the Global 2000.
Sumble → Buying signals from tech stacks, people data, & active projects.
Terret → The answer-to-action engine for revenue teams.

Hey y’all! 👋

Wild week in gtm-tech land. HubSpot acquired Warmly and Zoom acquired Common Room. This comes just after the acquisition of Pocus by Apollo.io. I suspect consolidation continues to happen in the space.

All the while, more companies are deciding to build certain parts internally. Cursor’s Head of Growth, George Hou, gave us a look behind the curtain of what he built at Cursor (one of the wildest in-house builds I’ve seen).

This week, we’re graced with the presence of another goat of gtm, Kyle Norton. Kyle is the CRO at Owner.com, runs The Revenue Leadership Podcast/Newsletter, and (according to my calculations) is the most AI-pilled CRO in all of SaaS. He recently published a piece titled “Don’t buy your GTM brain” (worth reading in full, if you haven’t already).

The “Build vs. Buy” question is on every GTM leader's mind right now.

So, after reading Kyle’s piece on it, I caught up with him to go a layer deeper on this topic (and how it works at Owner.com). I also share my own experience from the last two years of co-building GTM engines/AI workflows alongside internal teams.

In this piece, we cover:

How AI changed the calculus in favor of Build>Buy
The pitfalls of building (it’s not all sunshine and rainbows)
The risk of outsourcing (buying) your intelligence layer
Why you can’t outsource your AI strategy

Alright, let’s get into it.

How AI changed the calculus in favor of Build>Buy

For most of the last decade, build vs buy wasn’t much of a debate. Building was slow, expensive, and, unless you had spare engineers and a very specific need, you bought the tool and moved on.

AI changed the calculus. Since the model jump in late 2025 (the 4.6 moment), building went from “expensive, slow, probably not worth it” to a real option. You can spin up a working prototype in an afternoon. Things you would have paid a vendor six figures for, you can now build yourself and customize to your precise needs.

I’ve personally seen this up close. For 18 months, I embedded inside teams to build+ship AI-powered GTM systems (things like: data orchestration, signal-based selling, scoring, routing, ICP mapping, automated outbound, and more). The results of these systems were often magical. I saw the possibility of AI to create real leverage.

The ROI ceiling (with AI) is higher than it used to be. Old sales automation got you a 10-25% bump. The right AI build can double+ a team’s output.

Here’s what Kyle said:

The old build vs buy conversation usually centered on cost, implementation time, customization, and whether engineering had the capacity. Those still matter, but they are incomplete for AI.
The better AI build vs buy filter has 2 categories.
First, infrastructure. These are the parts of the stack where reliability matters more than differentiation. Dialers, core CRM plumbing, enrichment pipes, call recording, data warehousing, identity, permissions, security, and the underlying models in most cases. Buy these unless you have an unusually strong reason not to.
Second, intelligence. These are the parts of the stack where your company’s unique judgment matters. ICP definitions, lead scoring logic, account prioritization, territory design, pre-call research, deal strategy, customer context, coaching philosophy, messaging, qualification standards, and the evaluation loops that determine whether AI output is actually good.
That second category is where I get much more cautious.
At Owner.com, the point is not to build AI for the sake of building AI. That’s AI performance theater. The point is to build systems that make our GTM motion better because they encode what we know about our customer, our market, our reps, and our operating model.
That is why the line I used at SaaStr matters: buy your infrastructure, build or own your intelligence.
“Own” is important because it does not always mean build every component from scratch. You can use vendors and still own the intelligence if you control the data, understand the logic, can export the memory, can evaluate the outputs, and can move the learning if you need to. You can also build something internally and still fail to own the intelligence if it is a fragile one-off workflow nobody understands.
Ownership is not about ego. It is about control, portability, and compounding advantage.

We’ll come back to this point.

The pitfalls of building (it’s not all sunshine and rainbows)

Building is easier now. But also messier. Here are some pitfalls to avoid:

Swimlanes.

Inside a hyper-growth company, it’s never one team executing a tidy little roadmap. At Owner.com, Kyle has three different groups shipping production AI: an applied AI function under BizOps and data, the product org, and RevOps. Kyle shared an example where one team built a tool, but it was incinerating API calls into the CRM, wasn’t compliant with another piece of their stack regulations, and broke part of the rep workflow somewhere else. They understood the adjacent motion well enough to build for it, and not well enough to avoid breaking it. Kyle’s response wasn’t “stop.” It was “build it with RevOps, dedicate me engineers who work only on GTM tech, and do the requirements and roadmap properly.” You can’t have one person YOLO a tool that breaks other things downstream.

You need an actual engineer.

Not a “GTM engineer” in the LinkedIn sense, which has come to mean a Clay-table operator building lists and a few automations. Kyle calls his function applied AI on purpose, to draw that exact line. Once something has to run in production every day, you need real software engineers. Kyle’s discipline is to push everything into GitHub so a human can inspect what exists, and to not run tools whose outputs you can’t see.

Budget for maintenance.

When I was consulting, we would build the engine and then “pass the keys” to the team. But we would have problems after we left if there wasn’t a person (or team) in-house to maintain (and build on) the engine we deployed. Because the systems were complex (and in some cases brittle), a CRO of a Series A company is not going to open the workflow builder to rewrite ICP logic when the market shifts, or debug a chain that broke because something upstream changed. That isn’t a knock on them. It’s not their job, and they shouldn’t have to reverse-engineer a system they didn’t build. But you have to budget for this reality.

Things decay, and some should be killed.

Kyle revisits internal builds around the 90-day mark and asks whether each one is still worth it. They’ve deprecated things. They’ve even killed things and then brought them back. One example: their lead-routing system worked well, then the person who built it got pulled onto other priorities, it degraded, reps drifted back to assigning leads by hand, and they had to rebuild it to win them back.

You need evals.

Evals are how you know the thing actually works. They are often the difference between a V1 that demos well and a production tool reps use every day. Most of the work in closing that gap is boring. When Owner.com built AI pre-call research, the applied AI lead flew to Toronto and sat beside the reps for a week. They would hand a rep a batch of leads, watch them work it, hear “this is weird” or “this is wrong, here’s why,” go fix it, hand them a fresh batch, run it again. The feedback in those sessions becomes the product. Builders focused on these feedback loops are indistinguishable from an early-stage founder building alongside their first customers.

Most teams treat the launch as the finish line. In reality, it’s the starting line. The real cost of “build” isn’t the build; it’s the standing capacity to keep the thing alive after it ships. If you can’t fund that capacity, you should buy.

The risk of outsourcing (buying) your intelligence layer

Buy your infrastructure.

The dialer, the CRM plumbing, enrichment pipes, call recording, the underlying models. The places where uptime, reliability, compliance, and scale matter more than uniqueness. There’s no prize for vibe-coding a mediocre dialer that goes down during a call blitz on a Tuesday morning on the last week of the quarter.

Build your intelligence (or at least own it).

ICP definitions, scoring logic, account prioritization, pre-call research, deal strategy, coaching philosophy, messaging, and the eval loops that decide whether the AI’s output is any good. The places where your company’s judgment is the actual product.

The reason this matters more with AI than it did with old software is that AI systems learn from the workflow and compound. The risk is rented learning. Here’s how Kyle explained it:

The risk is not that AI vendors are bad. Many of them are excellent. The risk is that GTM leaders treat every AI decision like normal SaaS procurement. The normal SaaS procurement process asks: “does this tool solve the problem?”
AI-native procurement also asks: what does this tool learn, where does that learning live, and who controls it?
The worst version is a black box that owns both the workflow and the memory. You get productivity, but the learning compounds somewhere else. The vendor gets smarter across your usage. Your company gets dependent.
Again, that might still be worth it in some cases. But it should be a conscious trade, not an accidental one.

“Own” does not mean “build from scratch.” You can use vendors and still own the intelligence if you control the data, understand the logic, can export the memory, can evaluate the outputs, and can move the learning when you need to. The inverse is equally dangerous. You can build something fully in-house and still fail to own it, if what you built is a fragile one-off that nobody left in the building understands.

Why you can’t outsource your AI strategy

The intelligence layer has to stay yours, and the capability to build and maintain it has to live inside your office walls (digitally). You can’t buy your brain from a vendor, and you can’t outsource your AI strategy either.

Which is why the most interesting thing in my conversation with Kyle wasn’t the framework. It was him. He’s a CRO who gets his hands dirty and thinks like a product leader, and that combination is what future GTM leaders will look like, more and more.

I asked him whether a CRO should know how to build a product roadmap. Two years ago, he would have said, no. Today, he said, “Yes, or at least someone senior on the revenue side has to.” His path into systems thinking came from Shopify, where if you couldn’t speak Product, you were treated as lesser than. He learned the discipline to be taken seriously there, and then realized the frameworks themselves were the unlock as a CRO (customer discovery with reps to build requirements, user stories, something close to Agile inside RevOps, etc.).

Kyle’s results of owning the GTM brain in-house speak for themselves. At Owner.com, an AE at ~$150k OTE brings in roughly $3M ARR. A 20x comp-to-close ratio compared to their competitors running door-to-door motions.

Looking forward

Kyle shared where he lands on the quickly evolving debate of Build vs. Buy:

I am bullish on AI vendors. I am also bullish on internal GTM engineering. The answer is not one or the other. The winning companies will be pragmatic. They will buy a lot of infrastructure. They will use best-in-class vendors where vendors are clearly better. They will move fast.
But they will be extremely deliberate about the intelligence layer. They will know what context matters, what memory should persist, what workflows create proprietary learning, and what parts of the system need to remain portable.
That is how AI maturity compounds. One good workflow becomes reusable context for the next workflow. One evaluation loop improves the next model output. One proprietary memory layer makes every future agent better.
The companies that win AI-native GTM will not have the most tools. They will not be the companies with the flashiest demos.
They will be the companies whose systems get smarter every week because they own the memory that matters.
Don’t build everything but don’t buy your brain.

Buy your infrastructure, build your intelligence. But don’t build a brain you can’t keep alive, either.

That’s it for today!

Thanks to Kyle Norton for the conversation. Go read his original piece, “Don’t buy your GTM brain,” over at The Revenue Leadership Podcast and subscribe to his newsletter + podcast.

And, as always, thank you for your attention and trust. I do not take it for granted.

See you next time,
Brendan 🫡

Related posts:

The Signal

Discussion about this post

Ready for more?