The real build vs. buy question: “Do we want to own this?”

Takeaways from our live panel with G2, HubSpot, and Gong on how revenue teams are actually making AI build vs. buy decisions.

Every enterprise AI conversation eventually hits the same wall: build it yourselves, or buy it from someone else. During a recent webinar, we brought together three people who make that call— Shefali Raghavan (SVP of GTM Strategy & Operations, G2), Kelly Sarabyn (Director of Technology Partnerships, HubSpot), and Gong’s own Graham Miller (GTM AI Strategy & Enablement Lead, Gong) to share their perspectives and lessons learned.

The headline from 45 minutes of discussion: nobody on the panel thinks build vs. buy is really a binary question anymore. It's a dial, and where you set it depends on a much narrower question than "could we build this?"

A few numbers framed why this topic is landing differently in 2026 than it would have a year ago: research shows the vast majority of revenue teams are already using AI in some capacity, but a PwC study found that most of AI's economic value is being captured by a small fraction of organizations — a widening gap between the teams getting real ROI and everyone else.

At the same time, conversations between buyers and AI vendors that touch on building in-house have risen sharply over the past six months, and research from Retool has found that roughly a third of organizations have already replaced an existing tool with a custom AI-built system, with the large majority planning to build more before the year is out.

Shefali's framing set the tone early: the instinct to ask can we build this is almost always the wrong starting point, because with AI, the answer is usually yes. The better question is where the differentiation actually lives — in the underlying capability itself, or in how you apply that capability to your own data, workflows, and operating model.

Her rule of thumb: don't rebuild mature, horizontal capabilities that other companies have entire product and engineering teams dedicated to perfecting — CRM, conversational intelligence, enrichment. Reserve build energy for the orchestration layer: how you prioritize accounts, interpret signals, and route work. That's the layer worth owning, because it's specific to how your business actually operates.

Kelly and Graham both converged on the same underlying test, just from different angles. Kelly's version is total cost of ownership: it's easy to compare build vs. buy as a one-time cost, but the real comparison is what it costs to keep iterating, governing, and securing that system as the company scales. Graham's version is about criticality: a low-stakes, non-critical workflow is a great place to let people experiment and build; anything touching customer data or a critical revenue workflow gets immediate, hard scrutiny because the data quality and governance bar is completely different.

All three panelists agreed that AI is making building faster than ever before, but they also shed light on some not-so-obvious costs of that speed that show up later:

• Shadow builds. When everyone can spin up a working prototype in a weekend, you can end up with dozens of one-off tools nobody centrally tracks, also known as modern shadow IT. If the person who built it leaves, the institutional knowledge of how it works often leaves with them.
• Quality and hallucination risk. Something produced by an AI workflow in 30 minutes isn't automatically correct. The panel's shared practice: keep a human in the loop, especially before pointing anything AI-built at your most important customer segments.
• The "telephone game" of orchestration. Graham's description of AI harnessing stuck with the room; chain enough individual AI workflows together without careful design, and the signal quietly drifts, the same way a message degrades passed down a line of people, until the final output barely resembles the original intent.
• The mental tax on non-engineers. Teams built for go-to-market work are increasingly finding themselves learning GitHub, Docker, and even software development fundamentals just to keep up. This is a real cost that rarely makes it into the build vs. buy math.

Shefali offered a useful three-part lens for time-to-value: prototype, product, and operating capability. AI has dramatically compressed the time to get to a working prototype and meaningfully helped with parts of product development. What it hasn't eliminated is the work required to build an operating capability that hundreds of people can actually rely on. Mistaking a fast prototype for a finished capability is where build vs. buy decisions tend to go wrong.

Asked for one piece of advice for anyone facing this decision by tomorrow, the panel's answers converged:

• Don't start with "can we build it." Start with where the differentiation lives, and whether you actually want to own that layer once the excitement of the prototype wears off.
• Identify who owns the domain expertise for the thing you're building — and make sure that person is actually in the room.
• If it doesn't tie to a clear, tangible business outcome, you're enabling activity, not strategy.

Build vs. buy was never really about which side you land on. It's about being honest with yourself about ownership and building only the parts of your stack that actually earn you a competitive advantage.