Agentic Coding Tools Are Making 'Build vs. Buy' a Real Decision Again — Here's How to Make It Well

McKinsey's finding that 32% of organizations have skipped a software purchase because agentic coding tools made building the equivalent functionality viable is a meaningful shift — for years, the default answer for most functionality outside an organization's core competency was 'buy,' because building and maintaining software was expensive and slow relative to a mature vendor's product. Agentic coding tools genuinely lower the cost and speed barrier to building. But lower cost to build doesn't automatically mean building is the right choice — it means the decision is worth actually making deliberately again, rather than defaulting to either option.

What Actually Changed — and What Didn't

Agentic coding tools reduce the upfront development cost and time for building software, sometimes dramatically. What they don't reduce nearly as much: the ongoing maintenance burden, the security and compliance responsibility that shifts entirely to your organization, the need for someone internally to understand and evolve the system as requirements change, and the opportunity cost of your team's attention going toward maintaining internal tooling instead of your actual core product or service. The initial build cost dropping is real and significant — but it's only one term in the total cost of ownership equation.

A Practical Framework for the Decision

• Is this functionality close to your core competitive differentiation, or is it commodity infrastructure? Building close to your differentiation is more often worth it; building commodity functionality that a vendor already does well rarely is, even with lower build costs
• What is the realistic multi-year maintenance cost, not just the initial build cost — factor in someone needing to understand, secure, update and eventually replace the system as your needs or the underlying technology change
• How quickly does this category of software evolve? Fast-evolving categories (security, compliance-adjacent tooling, anything with frequent regulatory changes) favor a vendor who dedicates a full team to keeping pace, even if your initial build looks comparable on day one
• What happens to institutional knowledge if the person who built it with an agentic tool leaves? A system built quickly by one person can be harder to hand off than either a well-documented vendor product or a system built more traditionally with broader team involvement
• Would buying free up your team to work on something with more differentiated value than either building or maintaining this specific piece of functionality?

The Practical Takeaway

Agentic coding tools have made 'build' a genuinely more viable option across a wider range of software categories than it used to be — that's a real and useful shift. But the right response is to make the build-vs-buy decision deliberately, using a framework like the one above, rather than defaulting to 'we can build it now' simply because the initial development cost dropped. The categories where building now makes sense are real, but they're a subset of everything agentic tools technically make buildable.