Every good engineering leader already makes this build, buy, or partner assessment for any meaningful tool decision. Core criteria have been time, cost, control, and strategic differentiation. That calculus isn't new. What's new is that AI can now do things that used to be off the table entirely, which makes the "could we build it" side of the equation look a lot more real than it used to, and in some ways it feels like that shift happened overnight.

Modern AI tooling multiplies engineering output in ways no prior generation of tooling really has. Teams using it daily are shipping twice the pull requests of those that don't, leading to a real shift in what a small team can realistically take on. But with that comes uncertainties many don't yet have the experience to answer: token costs that swing unpredictably, outputs that vary run to run, governance and data exposure questions. One company reportedly ran up a $500 million AI bill after forgetting to set usage limits, another burned through its entire year's AI budget by April. That uncertainty is real, and it's part of the calculus now too.

Judgement You Can't Prompt

But speed and judgment aren't the same thing. AI can execute faster than ever. It can't yet tell you what's worth building, or catch the problem you didn't know to ask about. It cannot tell you whether the output is actually right. One study of agent-authored pull requests found the majority get merged with little more than an automated check and a rubber stamp, and the quality problems just surface later.

I am not making this argument from the sidelines. Our engineering and GTM teams use Claude.ai and Claude Code daily, for the same reasons any team would: it's a real multiplier on execution. What we've learned working with it daily is exactly the point of this piece. It's excellent at well-defined tasks, quickly finding and applying fixes, generating an enhancement where the pattern exists, drafting a first pass of a presentation, or pulling together documentation. It's often confidently wrong on the judgment calls sitting just outside that scope.

Calculating the Cost

Any engineer who has owned production code knows that the real cost is in everything that keeps it running afterward. AI can now handle some of that watching and patching on its own, but the agent is a risk itself, so someone has to govern it. This isn't hypothetical: incidents tied to agents given too much autonomy, from unauthorized actions to full breaches, have already made headlines this year. The data model that held up at 50,000 customers starts cracking at 500,000. Security is never a one-time checkbox, it's a standing obligation that shifts as your product grows and regulations change. And every upgrade, patch, and API change downstream is still something your team has to notice and account for before a customer does, agent or not. These agents will keep getting more capable, and fast, but accountability for the risk and the results doesn't move with them.

That's the honest cost of "we could just build it." Not v1. v40, eighteen months from now, maintained by whoever inherited it.

Building Relationships

Judgment about people is the thing AI still can't replicate. Managing customers well runs on relationships, not rules: knowing which customer to ask for something and which to leave alone this quarter, reading an account that looks healthy on paper but isn't, sensing when a message technically follows policy but is wrong for the moment. A model makes decisions too, but it has no memory of this specific customer, no ear for the tone shift in their last email, no gut sense that something's off before the numbers show it. That's not a data gap. It's a human one.

Cross-Customer Learning

There's another advantage that doesn't come up enough. When you build in-house, your solution only ever gets smarter about your own data, your own edge cases, your own history. It's a closed loop.

A team that builds this as their actual product sees patterns across many companies doing the same job differently: what health scoring model actually predicts churn, which reference request cadence burns out advocates, which onboarding sequence actually gets a new advocate to their first reference. An internal build doesn't have visibility into any of that. It only ever sees your own data, so it never accumulates that field knowledge in the first place. You're not just buying software, you're buying a team with a vested interest in staying ahead of the category, trying new things and setting the standard, instead of just keeping up with it.

Build vs. buy was never really about capability. It was about where you want your team's attention going. AI hasn't changed what the question is, only how tempting one answer looks. 

Final Verdict

My rule: Build when it's narrow, internal, and nobody outside your team will see it. Buy or Partner when it's customer-facing, needs to scale past what you can predict, or depends on judgment you haven't spent years building. Underneath it all is one real test: is this core to your business, worth owning and differentiating on, or just necessary, in which case let someone else's core competency carry it.  That's the bet we've made with Champion: that the relationships driving your growth deserve a platform and a partner, not just a build.