The “buy vs build” debate is as old as the software industry itself. For decades, the default answer for most teams has been “buy”, and for good reason. Building software is expensive, slow, and unpredictable. Off-the-shelf solutions, while imperfect, get you to market faster and let you focus on your core business.

But something has shifted. Fundamentally.

AI coding agents have compressed the time and cost of building custom software by an order of magnitude. What used to take a team of engineers weeks to scaffold, integrate, and ship can now be orchestrated by a single engineer with strong prompting skills in a matter of days, sometimes hours. And that changes the entire buy-vs-build equation.

The Old Calculus

The traditional reasoning for “buy” was straightforward:

• Time to market: Building takes months; buying takes days.
• Maintenance burden: Someone else handles updates, patches, and infrastructure.
• Cost: A SaaS subscription is cheaper than a team of engineers.
• Risk: Proven platforms reduce the risk of building something that doesn’t work.

Every one of these assumptions was reasonable; and every one of them is now under pressure.

What AI Changed

With tools like Claude Code and other AI coding agents, the cost curve of “build” has collapsed. I’m not talking about generating boilerplate or autocompleting functions. I’m talking about full-feature implementation: designing data models, writing business logic, creating API endpoints, building UI components, writing tests; all orchestrated through well-crafted prompts and agent workflows.

The key insight is this: the bottleneck has moved. It’s no longer the engineering effort that makes “build” expensive. It’s the decision-making: knowing what to build, why, and how it fits into the broader product.

I wrote about this shift in a recent post about reviving a 3-year side project in one week using AI agents. The thesis there (and it’s even more relevant here) is that the people who will thrive in this era are those who combine three things: deep software engineering knowledge, strong product sense, and the ability to set up and orchestrate AI agents. Miss any one of these three and you’ll either build the wrong thing, build it poorly, or not build it at all.

When “Buy” Still Wins

Let me be clear: I’m not arguing that “buy” is dead. There are categories where buying remains the obvious choice and will for a long time.

Third-Party Integrations and Ecosystems

Some platforms exist primarily because of the integrations they’ve already negotiated. Think payment processors, marketing automation tools that connect to dozens of ad networks, or HR platforms that integrate with payroll providers across different countries. The engineering effort to build the integration is often trivial; what’s not trivial is the operational overhead: the partnership agreements, the API access approvals, the compliance certifications, the weeks of back-and-forth with third-party teams. If you need to be live next month, buying the platform that already has those integrations approved and operational is the right call.

Infrastructure Platforms

AWS, GCP, Azure: these are not things you replicate. The capital expenditure, the global network of data centres, the decades of operational expertise. These are “buy” decisions by default, and that won’t change. The same applies to specialised infrastructure: CDNs, DNS providers, managed database services. The economies of scale make building your own version irrational for all but the largest organisations.

Platforms Built on Proprietary Data

Google’s search index. Amazon’s purchase history. Meta’s social graph. These platforms are valuable not because of their software (which is sophisticated, certainly) but because of the data moats they sit on top of. You cannot replicate that data. The only way to access it is through their platforms, their APIs, their terms. This is “buy” territory, full stop.

When “Build” Now Wins

Outside of those three categories, the argument for “buy” is weakening rapidly. Consider:

Custom CRM and email campaigns. Enterprise CRM platforms charge thousands per month for functionality that, when you strip away the integrations, is essentially: store contacts, segment them, send emails on a schedule. With AI agents, you can build a tailored version (one that fits your exact workflow, your exact data model, your exact customer journey) in days rather than years.

I did exactly this for Calendrz, my calendar-mirroring platform. We had been evaluating HubSpot for email drip campaigns: the usual onboarding sequences, re-engagement flows, that sort of thing. The platform is excellent, but we didn’t need 90% of what it offered. What we needed was a targeted set of email sequences, deeply integrated with our own user lifecycle data, with full control over timing and content. So instead of paying for HubSpot and spending weeks configuring it to fit our model, I built a custom solution with AI agents. It took a fraction of the time the HubSpot integration would have taken, costs nothing to run, and does exactly what we need; nothing more, nothing less.

Internal tools and dashboards. The “internal tools” SaaS category (think Retool, Appsmith, and the like) exists because building admin panels and dashboards used to be tedious, low-priority work that engineers resented. AI agents have eliminated that friction. You can describe the dashboard you need, the data sources, the filters, and have a working tool in an afternoon.

Workflow automation. Zapier, Make, n8n: these are wonderful platforms for connecting services together. But when your automation requires custom logic, conditional branching based on domain-specific rules, or tight integration with your own database, you quickly hit the limits of visual builders. An AI-built custom automation script is often simpler, more maintainable, and more powerful.

The Hidden Cost of “Buy”

There’s a cost to buying that rarely appears in the ROI spreadsheet: conformity.

When you buy a platform, you conform to its data model, its workflow assumptions, its upgrade schedule, its pricing tiers. You build your processes around its limitations. And over time, that conformity compounds. Switching costs increase. Your team develops expertise in someone else’s platform rather than in your own domain. You lose optionality.

When you build (especially when you build quickly, with AI) you retain full control. Your solution evolves with your product, not with someone else’s roadmap. You’re not waiting for a vendor to prioritise the feature you need. You’re not paying for a thousand features you don’t use to get the three you do.

The Team That Makes “Build” Work

Here’s the part that doesn’t get enough attention: AI doesn’t make “build” easy. AI makes “build” easy for the right people.

An engineer who tries to build a complex feature “by hand” — writing every line, designing every component from scratch, without leveraging AI agents — is making the strongest possible argument for “buy.” The economics simply don’t work. By the time they’ve finished, they could have been running on an off-the-shelf solution for months.

But an engineer who knows how to decompose a problem, craft precise prompts, orchestrate multiple AI agents in parallel, review and correct the output, and ship with confidence? That person has fundamentally different economics. Their “build” cost is a fraction of what it used to be, and the result is a custom solution that fits like a glove.

This is why I keep coming back to the three-legged stool: software engineering knowledge (to understand what the AI is producing and to course-correct when it goes wrong), product sense (to know what to build and what to skip), and agent orchestration skills (to actually drive the AI effectively). Teams that invest in developing these three competencies across their engineers will find that “build” is suddenly viable for a much wider range of problems than it was even a year ago.

Teams that don’t invest in these skills? For them, “buy” remains the right answer: because their “build” cost hasn’t changed.

The New Default

I’m not suggesting that every organisation should build everything from scratch. That would be as dogmatic as the old “always buy” stance. What I am suggesting is this: the default has shifted.

The old default was “buy unless you have a very strong reason to build.” The new default, for teams with strong AI-augmented engineering capability, is closer to “build unless you’re dealing with infrastructure, proprietary data, or complex third-party ecosystems.”

That’s a meaningful shift. And it’s one that will only accelerate as AI coding tools continue to improve.

The question is no longer “can we afford to build this?” The question is “can we afford to have our core workflows running on someone else’s platform when building our own is now this accessible?”

For a growing number of teams, the answer is clear.